除了性能改进之外，什么时候应该更喜欢 ThreadLocal 而不是同步？答案

【问题标题】：When should one prefer ThreadLocal over synchronization, apart from for the performance improvement?除了性能改进之外，什么时候应该更喜欢 ThreadLocal 而不是同步？
【发布时间】：2016-03-22 15:04:35
【问题描述】：

除了性能改进之外，什么时候应该更喜欢ThreadLocal 而不是同步？请用一个真实的例子来解释。

【问题讨论】：

我读过的东西——你可以用它以线程安全的方式共享非线程安全的类。网上有很多SimpleDateFormat的例子。

标签： java multithreading thread-local

【解决方案1】：

ThreadLocal 不能替代synchronized。 ThreadLocal解决的主要问题是如何在应用程序中管理每个线程的static数据。

static 是您应该尽量避免的事情：这是不可测试、脆弱代码的秘诀。

【讨论】：

【解决方案2】：

当您使用 ThreadLocal 变量时，这些变量只能由使用它的线程查看和操作，其他线程无法看到它们。当线程也死时，线程局部变量也死了。在使用线程池时应该小心使用 ThreadLocal 变量。

ThreadLocal 变量被放置在一个称为 Thread 私有堆栈的特殊内存空间中。

共享变量被放在堆内存空间中，它们在所有线程之间共享，它们要么同步，要么不同步。

所以它更多的是关于用例而不是性能。

可以使用 ThreadLocal 变量来保持与某个数据库的连接，其中该连接仅与当前线程相关联，不需要其他线程查看它并且需要同步它。缓存 - 例如，内存映射或列表中的共享，在服务器应用程序中的所有线程之间共享，并且必须同步。

【讨论】：

【解决方案3】：

使用线程的唯一原因是出于性能原因（或者您可能喜欢混淆；）。

AFAICS 如果您打折性能，则没有理由使用线程、ThreadLocal 或同步。

【讨论】：

性能并不是使用线程的唯一原因。这甚至不是最初的原因。早在多处理器硬件从实验室中逃脱之前，多线程程序就已在现实世界中使用。线程旨在成为事件驱动编程的一种更简洁的替代方案——一种构建响应多个异步输入的程序的方法：每个线程只侦听一个输入源，并以纯同步、程序化的方式处理事件，保持局部变量中的状态。易于理解...直到您需要线程相互交谈为止。

【解决方案4】：

ThreadLocal 在线程中提供全局变量访问。当您想要跨方法共享变量并仍保留 Thread 范围时，这将有所帮助。

J2EE 应用服务器使用 ThreadLocal 来跟踪事务、安全上下文而无需绕过

【讨论】：