问ThreadLocal变量的性能

EN

运行未发布的基准测试，在我的机器上，ThreadLocal.get每次迭代大约需要35个周期。不是很多。在Sun的实现中，Thread中的自定义线性探测散列映射将ThreadLocal映射到值。因为它只被单个线程访问，所以它可以非常快。

小对象的分配需要类似的周期数，尽管由于缓存耗尽，在紧凑的循环中可能会得到一些较低的数字。

MessageDigest的建设可能会相对昂贵。它有相当多的状态，并通过Provider的SPI机制进行构造。例如，您可以通过克隆或提供Provider来进行优化。

仅仅因为在ThreadLocal中缓存可能比在create中缓存更快，并不一定意味着系统性能会提高。你会有额外的与GC相关的开销，这会减慢一切。

除非您的应用程序大量使用MessageDigest，否则您可能需要考虑使用传统的线程安全缓存。

在2009年，一些JVM在Thread.currentThread()对象中使用非同步HashMap实现了ThreadLocal。这使得它非常快(当然，不像使用常规字段访问那样快)，并确保在Thread终止时ThreadLocal对象得到清理。在2016年更新这个答案，看起来大多数(所有？)较新的JVM使用带线性探测的ThreadLocalMap。我不确定这些实现的性能--但我不能想象它会比早期的实现更糟糕。

当然，现在new Object()的速度也非常快，垃圾收集器也非常擅长回收生命周期较短的对象。

除非您确定对象创建的开销很大，或者您需要逐个线程地保存某些状态，否则您最好选择更简单的在需要时分配解决方案，并且只在分析器告诉您需要时才切换到ThreadLocal实现。

在优化之前，@Pete是正确的测试。

如果与实际使用相比，构建MessageDigest有任何严重的开销，我会感到非常惊讶。

错过使用ThreadLocal可能是泄漏和悬空引用的来源，这些都没有明确的生命周期，通常我不会使用ThreadLocal，除非我对何时删除特定资源有一个非常明确的计划。