mobile wallpaper 1mobile wallpaper 2mobile wallpaper 3mobile wallpaper 4
Profile Image of the Author
Tsukimi
公告
欢迎来到我的博客！这是一条示例公告
标签
2316 字
6 分钟
Thread-Local Storage 线程本地存储（Thread-Local Storage）
2026-06-13
程序设计
程序设计
/
并发编程

一、为什么需要线程本地存储#

一个 Web 服务器每个请求都要查数据库。最简单的方案：每次请求创建一个连接，用完关闭。但数据库连接创建成本高（TCP 握手 + 认证），频繁创建销毁会拖垮性能。连接池是标准解决方案——提前创建 N 个连接，请求来了从池子里取，用完还回去。

但多线程共享一个连接池，每次取/还连接都要加锁。锁争用在低并发时不是问题，高并发时却是瓶颈。更麻烦的是：连接有状态（事务、临时表、预处理语句），连接 A 上开始的事务不应该被拿到连接 B 的线程看到。

线程本地存储（Thread-Local Storage，TLS）提供了一种简洁的解法：每个线程维护自己的连接池实例，取连接不需要锁，连接的状态也不会被其他线程干扰。线程 A 的连接池和线程 B 的连接池完全隔离——没有共享，就没有竞争。

TLS 的应用远不止连接池。随机数生成器需要每个线程独立的种子，否则多线程并发调用 rand() 会产出相同的序列。请求上下文（用户身份、trace ID）需要在线程内传递但不要污染全局状态。这些场景的共同特征：数据需要跨函数调用传递，但不需要跨线程共享。

二、现实类比#

想象一个工厂里每个工人都有自己的工具箱。工人 A 拿自己工具箱里的锤子，工人 B 拿自己工具箱里的锤子——两个人互不干扰，不需要排队等同一把锤子。如果所有工人共用一个工具箱（共享内存），取工具就得排队（加锁），效率自然低下。TLS 就是给每个线程发一个专属工具箱。

三、核心思想#

TLS 为每个线程维护一个独立的变量副本。写入时只修改当前线程的副本，读取时只读当前线程的副本——没有任何共享状态，因此不需要任何同步操作。

flowchart TD subgraph 全局变量 "ThreadLocal<ConnectionPool>" TL["ThreadLocal 实例"] end TL --> T1["线程 1 的连接池"] TL --> T2["线程 2 的连接池"] TL --> T3["线程 3 的连接池"] T1 --> R1["请求 A: getConnection()"] T2 --> R2["请求 B: getConnection()"] T3 --> R3["请求 C: getConnection()"]

3.1 实现机制#

TLS 的底层实现因平台而异：

  • C/POSIX：pthread_key_create / pthread_setspecific / pthread_getspecific。内部维护一个键值表，每个线程有自己的表项，通过键索引找到对应的值
  • Windows：TlsAlloc / TlsSetValue / TlsGetValue，原理类似
  • x86 架构：fs（32 位）或 gs（64 位）段寄存器指向线程局部存储区，访问 TLS 变量只需一次段寄存器间接寻址
  • Go：没有原生的 goroutine-local storage（刻意设计），用 context.Context 传递请求作用域数据
  • Java：ThreadLocal<T> 类，每个 Thread 对象内部有一个 ThreadLocalMap

3.2 核心操作与复杂度#

操作时间复杂度说明
读取（get）O(1)直接从当前线程的存储区索引
写入（set）O(1)直接写入当前线程的存储区
初始化O(1) 均摊首次访问时懒初始化
线程退出清理O(k)k 为该线程的 TLS 变量数量
Warning

TLS 最大的陷阱是内存泄漏。线程池中的线程不会退出，它持有的 TLS 变量也不会被回收。Java 的 ThreadLocal 尤其容易踩坑——线程池复用线程时，上一次请求的 TLS 数据可能被下一次请求读到。必须在请求结束时调用 remove() 清理。

四、变体与对比#

特性Thread-Local Storagecontext.Context（Go）闭包/函数参数全局变量 + 锁
作用域线程/goroutine 生命周期单次请求调用链单次函数调用全局
同步开销无无无有
传递方式隐式（线程自动关联）显式（参数传递）显式（参数传递）隐式（全局可见）
内存管理需手动清理GC 自动回收GC 自动回收手动或 GC
可测试性差（隐式依赖）好（显式注入）好（显式传入）差（隐式依赖）

Go 的 context.Context vs TLS：Go 刻意不支持 goroutine-local storage，改用 context.Context 传递请求作用域数据。这是显式优于隐式的设计哲学——数据从哪来、传给谁，在函数签名中一目了然。TLS 的问题是隐式依赖：函数内部突然读了一个 TLS 变量，调用者完全不知道，测试时也无法注入。context.Context 把依赖变成了参数，可测试性和可维护性都更好。

闭包/函数参数 vs TLS：最直接的「线程安全」方式是不共享——把数据作为参数一路传下去。但调用链很长时，中间层函数被迫接收和传递它们不关心的参数（参数膨胀）。TLS 解决了参数膨胀的问题，但代价是隐式依赖。这是一个工程权衡。

4.1 InheritableThreadLocal（Java）#

Java 提供了 InheritableThreadLocal，子线程创建时会自动继承父线程的 TLS 值。这在传递用户身份、trace ID 等请求上下文时很方便。但线程池场景下线程是复用的而非新建的，继承机制不会触发——阿里巴巴开源的 TransmittableThreadLocal（TTL）专门解决了这个问题，在提交任务到线程池时捕获当前线程的 TLS 快照，在 worker 线程执行前恢复。

五、多语言实现#

5.1 Go 实现#

Go 没有原生的 goroutine-local storage，但可以用 context.Context 实现类似效果：

package reqctx


import (
    "context"
    "fmt"
)


type contextKey string


const (
    keyRequestID contextKey = "requestID"
    keyUserID    contextKey = "userID"
)


// WithRequestID 将请求 ID 注入 context
func WithRequestID(ctx context.Context, id string) context.Context {
    return context.WithValue(ctx, keyRequestID, id)
}


// RequestID 从 context 读取请求 ID
func RequestID(ctx context.Context) string {
    if v, ok := ctx.Value(keyRequestID).(string); ok {
        return v
    }
    return ""
}


// WithUserID 将用户 ID 注入 context
func WithUserID(ctx context.Context, id string) context.Context {
    return context.WithValue(ctx, keyUserID, id)
}


// UserID 从 context 读取用户 ID
func UserID(ctx context.Context) string {
    if v, ok := ctx.Value(keyUserID).(string); ok {
        return v
    }
    return ""
}


// HandleRequest 模拟请求处理链
func HandleRequest(ctx context.Context) {
    ctx = WithRequestID(ctx, "req-12345")
    ctx = WithUserID(ctx, "user-42")


    // 调用链中任何函数都能从 ctx 读取请求作用域数据
    processOrder(ctx)
}


func processOrder(ctx context.Context) {
    fmt.Printf("处理订单: requestID=%s, userID=%s\n",
        RequestID(ctx), UserID(ctx))
}

Go 社区强烈推荐 context.Context 而非任何形式的 goroutine-local storage。context.WithValue 的开销极低（只是包装了一层），而且数据流是显式的——函数签名中 ctx context.Context 一目了然。

5.2 TypeScript 实现#

// 用 AsyncLocalStorage 实现 Node.js 的请求作用域数据
import { AsyncLocalStorage } from "async_hooks";


interface RequestContext {
  requestId: string;
  userId: string;
  traceId: string;
}


// 创建异步本地存储实例
const requestContext = new AsyncLocalStorage<RequestContext>();


// 模拟请求处理
function handleRequest(req: { id: string; user: string }): void {
  // 在 run 回调内，所有异步操作都能访问同一个 context
  requestContext.run(
    {
      requestId: req.id,
      userId: req.user,
      traceId: `trace-${Date.now()}`,
    },
    () => {
      processOrder();
    }
  );
}


function processOrder(): void {
  const ctx = requestContext.getStore();
  if (!ctx) throw new Error("No request context");
  console.log(`处理订单: requestId=${ctx.requestId}, userId=${ctx.userId}`);


  // 异步回调中也能访问
  setTimeout(() => {
    const ctx = requestContext.getStore();
    console.log(`异步日志: traceId=${ctx?.traceId}`);
  }, 100);
}


// 使用示例
handleRequest({ id: "req-001", user: "user-42" });

Node.js 的 AsyncLocalStorage 是 TLS 在异步世界的等价物——它利用 V8 的异步钩子追踪每个异步调用的「调用链」，确保 getStore() 返回的是触发当前异步操作的请求的上下文。在 Express/Koa 中，中间件通常在请求入口调用 requestContext.run()，后续所有中间件和路由处理器都能通过 requestContext.getStore() 获取请求作用域数据，不需要把 context 对象一路传递。

六、生产验证#

Java 线程池 —— ThreadLocal 与连接池#

HikariCP（Java 生态最流行的数据库连接池）虽然本身不使用 ThreadLocal 存储连接，但许多上层框架（如 Spring 的 TransactionSynchronizationManager）使用 ThreadLocal 存储当前线程的事务绑定连接。DataSourceUtils.getConnection() 先检查 ThreadLocal 中是否有已绑定的事务连接，有则复用，没有再从池中取。这种模式确保同一事务中的多次 DAO 调用使用同一个连接，无需在方法间显式传递。

Go 标准库 —— context.Context#

Go 标准库 的 context 包是 TLS 精神的 Go 式实现。从 Go 1.7 开始，context.Context 成为标准库的请求作用域数据载体。net/http 的 Request.Context()、database/sql 的 Conn.QueryContext()、gRPC 的拦截器——整个 Go 生态围绕 context.Context 构建请求链路追踪、超时控制、取消传播。Go 团队曾明确拒绝为 Go 添加 goroutine-local storage，context.Context 是唯一的官方方案。

Node.js —— AsyncLocalStorage#

Node.js 的 AsyncLocalStorage 基于 async_hooks 模块实现，从 v13.10 起稳定可用。APM 工具（如 OpenTelemetry、New Relic、DataDog）使用它实现无侵入的分布式追踪——不需要在每个函数中手动传递 trace ID，AsyncLocalStorage 自动将上下文绑定到异步调用链。

七、小结#

什么时候用#

  • 连接池：每个线程维护自己的数据库连接，避免锁争用和状态污染
  • 随机数生成器：每个线程独立的种子，避免多线程产出相同随机序列
  • 请求上下文：用户身份、trace ID、日志上下文等请求作用域数据
  • 日期格式化器：SimpleDateFormat 等非线程安全的工具类，用 TLS 避免每次创建新实例

什么时候别用#

  • 数据需要跨线程共享：TLS 是线程隔离的，不同线程之间看不到彼此的 TLS 数据
  • 线程池复用时忘记清理：请求结束后必须 remove() 或 delete，否则下一个复用该线程的请求会读到脏数据
  • 可以用参数传递的简单场景：调用链不深时，显式传参比 TLS 更清晰
  • Go 项目：用 context.Context，不要尝试在 Go 中实现 goroutine-local storage

八、参考资料#

支持与分享

如果这篇文章对你有帮助，欢迎支持作者或分享给更多人

赞助
Thread-Local Storage 线程本地存储（Thread-Local Storage）
https://blog.souloss.com/posts/programming/concurrency/concurrency-thread-local-storage/
作者
Tsukimi
发布于
2026-06-13
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时

SeqLock 序列锁（SeqLock）
工作窃取（Work Stealing）
相关文章 智能推荐
1
信号量（Semaphore）
程序设计 用计数器控制同时访问共享资源的线程数
2
Actor 模型（Actor Model）
程序设计 每个 Actor 独占自己的状态，通过消息通信
3
工作窃取（Work Stealing）
程序设计 空闲线程从忙碌线程那里偷任务
4
事件循环（Event Loop）
程序设计 单线程事件循环，把并发问题转化为队列处理
5
MVCC 多版本并发控制（MVCC）
程序设计 通过保存数据的多个版本让读操作不阻塞写操作
随机文章 随机推荐
1
Agent 规划架构：ReAct、Plan-and-Execute 与 Reflexion
AI 2024-12-16
2
为什么 Docker 使用分层镜像
技术科普 2024-03-13
3
写时复制（Copy-on-Write）
程序设计 2026-06-13
4
存储引擎：从磁盘到 B 树与 LSM 树
数据库 2024-05-18
5
系统调用：20 个 POSIX 接口
操作系统 2021-10-17
© 2026 Tsukimi. All Rights Reserved. / RSS / Atom / Sitemap
Powered by Astro & Tsukimi  Version 10.0.0