《Java特种兵》5.2 线程安全（二）

 5.2.4 final

在JMM中要求final域（属性）的初始化动作必须在构造方法return之前完成。换言之，一个对象创建以及将其赋值给一个引用是两个动作，对象创建还需要经历分配空间和属性初始化的过程，普通的属性初始化允许发生在构造方法return之后（指令重排序）。
似乎这个问题变得很可怕，因为在Java程序中得到的对象竟然有可能还没有执行完构造方法内的属性赋值，但在大部分情况下，对象的使用都是在线程内部定义的，在单线程中是绝对可靠的，或者说在单线程中要求使用对象引用时，该对象已经被初始化好。但如果在此过程中有另一个线程通过这个未初始化好的对象引用读取相应的属性，那么就可能读取到的并不是真正想要的值。在Java中final可以保证这一点，所以它可以避免这种类型的逃逸问题。
但是它并不能完全解决所有的逃逸问题，而只是确保在构造方法return以前是会被初始化的，无法确保不与其他的指令进行重排序，比如下面的代码：

如果有另一个线程调用静态方法read()，则可能得到testObject非空值，而此时有可能a=100这个动作还未执行（因为它可以与testObject = this进行重排序），那么操作的数据就将是错误的。
进一步探讨：如果final所修饰的不是普通变量，而是数组、对象，那么它能保证自己本身的初始化在其外部对象的构造方法返回之前，但是它本身作为对象，对内部的属性是无法保证的。如果是某些具有标志性的属性，则需要根据实际情况做进一步处理，才可以达到线程安全的目的。
经过JSR-133对final进行语义增强后，我们就可以比较放心地使用final语法了。但是我们想看看构造方法还没做完，变量是什么样子呢？普通变量和final变量到底又有什么区别呢？下面我们就写一段和并发编程没多大关系的代码来跑一跑看看。
代码清单5-7 构造方法未结束，看看属性是什么样子

在这段代码中，我们跳开了构造方法返回之前对final的初始化动作，而是在构造方法内部去输出这些final属性。这段代码的输出结果可能会让我们意想不到，大家可以自行测试，如果在测试过程中使用断点跟踪去查看这些数据的值，则可能在断点中看到的值与实际输出的值还会有所区别，因为断点也是通过另一个线程去看对象的属性值的，看到的对象可能正好是没有初始化好的对象。
这样看来，volatile和final在程序中必不可少吗？当然不是！
如果每个属性都使用这样的修饰符，那么系统就没有必要设置这样的修饰符了！其实它们是有一定的性能开销的！我们关注的是代码是否真的有并发问题，如果数据本身就是某些只读数据，或者这些Java对象本身就是线程所私有的局部变量或类似于ThrealLocal的变量，那么就没有必要使用这些修饰符了。
提到final，我们再补充一个相关的话题（该话题与并发编程无关）。当在方法中使用匿名内部类时，匿名内部类的方法要直接使用外部方法中的局部变量，这个局部变量必须用final来声明才可以被使用。很多人会问这到底是为什么？伪代码如下：

这其实是对一个语法的疑问，本身没什么好解释的，但是如果非要解释，或许我们可以从这个角度来理解：JVM本身也是一种软件平台，它设计了一种语法规则，自然也有它的局限性和初衷。在编译时，这个地方会自动生成一个匿名内部类，而本地变量a的作用域是在方法test()中，它如何能用到另一个内部类中呢？
其中一种方式是参数传递；另一种方式就是作为一个属性存在于匿名内部类对象中。不论哪一种方式都会在这个匿名内部类对象中有一份数据拷贝（如果本地变量是引用，那么拷贝将是引用的值），不过这似乎与外部定义本地变量时是否定义为final没有关系。
JVM在设计时并不知道我们的代码会怎么写，或者说它不明确在所创建的匿名内部类中到底会做什么，例如在代码中完全可以在内部创建一个线程来使用这个变量，或者创建一个任务提交给线程池来使用这个变量。如果是这样，匿名内部类的运行将与该方法本身的运行处于两个线程中，当外部方法可能已经结束时，那么相应的局部变量的作用域已经结束，自动会被回收，要保证匿名内部类一直可以使用该变量，就只能用拷贝的方法，这似乎还是与final没有多大关系。
我们现在回过头来回答：为何外部方法必须使用final定义这个这个变量？我们将上述结论反过来想，如果这个属性不是final修饰的，在匿名内部类中使用“同名”的变量操作，并且可以对它做任意修改，自然外部也应当能感知到。但是事实上不能感知到，因为这是一份数据拷贝，就像传递的参数一样，不是原来的数据。胖哥认为这种语法的设计手段是为了避免误解，语法上强制约束它为final修饰。
如果这里的a是一个引用，那么就只会拷贝引用值，而不是整个对象的内容，在内部修改引用所指向的对象不会影响外部，外部的final也无法约束其改变，但如果改变其对象内部的属性，只要外部还会使用这个对象，那么就会受到影响。

 5.2.5 栈封闭

栈封闭算是一种概念，也就是线程操作的数据都是私有的，不会与其他的线程共享数据。简单来说，如果每个线程所访问的JVM区域是隔离的，那么这个系统就像一个单线程系统一样简单了，我们把它叫作栈封闭。这样说是不是有点抽象，下面讲实际的例子。
通常在做Web开发时不需要自己去关注多线程的各种内在，因为容器给我们做好了，从前端请求就给业务处理分配好了数据，我们无须关注那些并发的过程，Web容器会自动给我们提供私有的Reqeust、Response对象的处理，因为它不会被其他的线程所占用，所以可以放心使用，它是线程绝对安全的（当使用Session或ServletContext时，它也在内部给你封装好了并发的控制）。
但这并不意味着程序永远不关注多线程与异步的问题，当需要并发去访问某些共享缓存数据时，当需要去操作共享文件数据时，当自定义多线程去并发做一些任务时，都必然会用到这些基本的知识体系来作为支撑，否则代码出现某些诡异的问题还不知道怎么回事。
比如在一个项目中，使用了Spring注入的DAO层，大家都应该知道Spring生成的对象默认是“单例”的，也就是一个类只会生成一个对应的实例。在这个DAO的许多方法中，使用StringBuilder进行SQL拼接，在DAO里面定义了StringBuilder，认为这个变量可以提供给许多的DAO层的方法共同使用，以节约空间，每个相应的方法都是对它做一个或多个append操作后，通过toString()获取结果String对象，最后再把这个StringBuilder清空。
先抛开并发本身的问题，这样做也根本节约不了什么空间，因为这个对象将拥有与这个DAO一样永久的生命周期占用内存，由于DAO是“单例”的，所以相当于永久的生命周期。我们节约空间的方式通常是希望它短命，在Young空间就干掉它，而不是让它共享。
继续看有什么并发的问题。虽然这个StringBuilder不是static修饰的，但由于它所在的这个DAO对象实例是“单例”的，由Spring控制生成，所以它几乎等价于全局对象。它至少会在这个类里面的所有方法被访问时共享，就算这个类里面只有一个方法也会有并发问题（因为同一个方法是可以被多个线程同时访问的，为何？因为它是代码段，程序运行时只需要从这里获取到指令列表即可，或者反过来理解，如果所有的代码都不能并行访问，那么多线程程序就完全被串行化了）。
如果数据区域发生共享就有问题了，多个线程可能在同时改一个数据段，这样没有任何安全策略的数据段，最终结果会是什么样子，谁也不清楚。本例中提到的StringBuilder就是一个共享的数据区域，假如有两个线程在append()，然后一个线程toString()得到的结果将有可能是两个线程共同写入的数据，它在操作完成后可能还会将数据清空，那么另一个线程就可能拿到一个空字符串甚至于更加诡异的结果。这样的程序很明显是有问题的。
如果改成StringBuffer，是否可行？
答曰：StringBuffer是同步的，但是并不代表它在业务上是绝对安全的，认为它安全是因为它在每一次做append()类似操作时都会加上synchronized的操作，但是在实际的程序中是可以对StringBuffer进行多次append()操作的，在这些append()操作之间可能还会有其他的代码步骤，StringBuffer可以保证每次append()操作是线程安全的，但它无法保证多线程访问时进行多次append()也能得到理想的结果。
难道我们还要在外层加一个锁来控制？
如果是这样的话，新的问题就出现了，这个类所有的方法访问到这里都是串行的，如果所有的DAO层都是这样的情况，抛开锁本身的开销，此时系统就像单线程系统一样在运行，外部的并发访问到来时，系统将奇慢无比。如果访问过大，就会堆积大量的线程阻塞，以及线程所持有的上下文无法释放，而且会越堆积越多，后果可想而知。
锁的开销是巨大的，它对于并发编程中的性能是十分重要的，于是许多大牛开始对无锁化的问题有了追求，或者说尽量靠近无锁化。在大多数情况下我们希望事情是乐观的，希望使用尽量细粒度化的锁机制，不过对于大量循环调用锁的情况会反过来使用粗粒度化的锁机制，因为加锁的开销本身也是巨大的。
关于栈封闭，除了使用局部变量外，还有一种方式就是使用ThreadLocal，ThreadLocal使用一种变通的方式来达到栈封闭的目的，具体的请参看下一小节的内容。

 5.2.6 ThreadLocal

虽然ThreadLocal与并发问题相关，但是许多程序员仅仅将它作为一种用于“方便传参”的工具，胖哥认为这也许并不是ThreadLocal设计的目的，它本身是为线程安全和某些特定场景的问题而设计的。
ThreadLocal是什么呢！
每个ThreadLocal可以放一个线程级别的变量，但是它本身可以被多个线程共享使用，而且又可以达到线程安全的目的，且绝对线程安全。
例如：

RESOURCE代表一个可以存放String类型的ThreadLocal对象，此时任何一个线程可以并发访问这个变量，对它进行写入、读取操作，都是线程安全的。比如一个线程通过RESOURCE.set(“aaaa”);将数据写入ThreadLocal中，在任何一个地方，都可以通过RESOURCE.get();将值获取出来。
但是它也并不完美，有许多缺陷，就像大家依赖于它来做参数传递一样，接下来我们就来分析它的一些不好的地方。
为什么有些时候会将ThreadLocal作为方便传递参数的方式呢？例如当许多方法相互调用时，最初的设计可能没有想太多，有多少个参数就传递多少个变量，那么整个参数传递的过程就是零散的。进一步思考：若A方法调用B方法传递了8个参数，B方法接下来调用C方法- D方法- E方法- F方法等只需要5个参数，此时在设计API时就涉及5个参数的入口，这些方法在业务发展的过程中被许多地方所复用。
某一天，我们发现F方法需要加一个参数，这个参数在A方法的入口参数中有，此时，如果要改中间方法牵涉面会很大，而且不知道修改后会不会有Bug。作为程序员的我们可能会随性一想，ThreadLocal反正是全局的，就放这里吧，确实好解决。
但是此时你会发现系统中这种方式有点像在贴补丁，越贴越多，我们必须要求调用相关的代码都使用ThreadLocal传递这个参数，有可能会搞得乱七八糟的。换句话说，并不是不让用，而是我们要明确它的入口和出口是可控的。
诡异的ThreadLocal最难琢磨的是“作用域”，尤其是在代码设计之初很乱的情况下，如果再增加许多ThreadLocal，系统就会逐渐变成神龙见首不见尾的情况。有了这样一个省事的东西，可能许多小伙伴更加不在意设计，因为大家都认为这些问题都可以通过变化的手段来解决。胖哥认为这是一种恶性循环。
对于这类业务场景，应当提前有所准备，需要粗粒度化业务模型，即使要用ThreadLocal，也不是加一个参数就加一个ThreadLocal变量。例如，我们可以设计几种对象来封装入口参数，在接口设计时入口参数都以对象为基础。
也许一个类无法表达所有的参数意思，而且那样容易导致强耦合。
通常我们按照业务模型分解为几大类型对象作为它们的参数包装，并且将按照对象属性共享情况进行抽象，在继承关系的每一个层次各自扩展相应的参数，或者说加参数就在对象中加，共享参数就在父类中定义，这样的参数就逐步规范化了。
我们回到正题，探讨一下ThreadLocal到底是用来做什么的？为此我们探讨下文中的几个话题。
（1）应用场景及使用方式
为了说明ThreadLocal的应用场景，我们来看一个框架的例子。Spring的事务管理器通过AOP切入业务代码，在进入业务代码前，会根据对应的事务管理器提取出相应的事务对象，假如事务管理器是DataSourceTransactionManager，就会从DataSource中获取一个连接对象，通过一定的包装后将其保存在ThreadLocal中。并且Spring也将DataSource进行了包装，重写了其中的getConnection()方法，或者说该方法的返回将由Spring来控制，这样Spring就能让线程内多次获取到的Connection对象是同一个。
为什么要放在ThreadLocal里面呢？因为Spring在AOP后并不能向应用程序传递参数，应用程序的每个业务代码是事先定义好的，Spring并不会要求在业务代码的入口参数中必须编写Connection的入口参数。此时Spring选择了ThreadLocal，通过它保证连接对象始终在线程内部，任何时候都能拿到，此时Spring非常清楚什么时候回收这个连接，也就是非常清楚什么时候从ThreadLocal中删除这个元素（在9.2节中会详细讲解）。
从Spring事务管理器的设计上可以看出，Spring利用ThreadLocal得到了一个很完美的设计思路，同时它在设计时也十分清楚ThreadLocal中元素应该在什么时候删除。由此，我们简单地认为ThreadLocal尽量使用在一个全局的设计上，而不是一种打补丁的间接方法。
了解了基本应用场景后，接下来看一个例子。定义一个类用于存放静态的ThreadLocal对象，通过多个线程并行地对ThreadLocal对象进行set、get操作，并将值进行打印，来看看每个线程自己设置进去的值和取出来的值是否是一样的。代码如下：
代码清单5-8 简单的ThreadLocal例子

关于这段代码，我们先说几点。
◎ 定义了两个ThreadLocal变量，最终的目的就是要看最后两个值是否能对应上，这样才有机会证明ThreadLocal所保存的数据可能是线程私有的。
◎ 使用两个内部类只是为了使测试简单，方便大家直观理解，大家也可以将这个例子的代码拆分到多个类中，得到的结果是相同的。
◎ 测试代码更像是为了方便传递参数，因为它确实传递参数很方便，但这仅仅是为了测试。
◎ 在finally里面有remove()操作，是为了清空数据而使用的。为何要清空数据，在后文中会继续介绍细节。
测试结果如下：
线程-6: value = (6)
线程-9: value = (9)
线程-0: value = (0)
线程-10: value = (10)
线程-12: value = (12)
线程-14: value = (14)
线程-11: value = (11)
线程-3: value = (3)
线程-5: value = (5)
线程-13: value = (13)
线程-2: value = (2)
线程-4: value = (4)
线程-8: value = (8)
线程-7: value = (7)
线程-1: value = (1)
大家可以看到输出的线程顺序并非最初定义线程的顺序，理论上可以说明多线程应当是并发执行的，但是依然可以保持每个线程里面的值是对应的，说明这些值已经达到了线程私有的目的。
不是说共享变量无法做到线程私有吗？它又是如何做到线程私有的呢？这就需要我们知道一点点原理上的东西，否则用起来也没那么放心，请看下面的介绍。
（2）ThreadLocal内在原理
从前面的操作可以发现，ThreadLocal最常见的操作就是set、get、remove三个动作，下面来看看这三个动作到底做了什么事情。首先看set操作，源码片段如图5-5所示。

图5-5 ThreadLcoal.set源码片段
图5-5中的第一条代码取出了当前线程t，然后调用getMap(t)方法时传入了当前线程，换句话说，该方法返回的ThreadLocalMap和当前线程有点关系，我们先记录下来。进一步判定如果这个map不为空，那么设置到Map中的Key就是this，值就是外部传入的参数。这个this是什么呢？就是定义的ThreadLocal对象。
代码中有两条路径需要追踪，分别是getMap(Thread)和createMap(Thread , T)。首先来看看getMap(t)操作，如图5-6所示。

图5-6 getMap(Thread)操作

在这里，我们看到ThreadLocalMap其实就是线程里面的一个属性，它在Thread类中的定义是：
ThreadLocal.ThreadLocalMap threadLocals = null;
这种方法很容易让人混淆，因为这个ThreadLocalMap是ThreadLocal里面的内部类，放在了Thread类里面作为一个属性而存在，ThreadLocal本身成为这个Map里面存放的Key，用户输入的值是Value。太乱了，理不清楚了，画个图来看看（见图5-7）。
简单来讲，就是这个Map对象在Thread里面作为私有的变量而存在，所以是线程安全的。ThreadLocal通过Thread.currentThread()获取当前的线程就能得到这个Map对象，同时将自身作为Key发起写入和读取，由于将自身作为Key，所以一个ThreadLocal对象就能存放一个线程中对应的Java对象，通过get也自然能找到这个对象。

图5-7 Thread与ThreadLocal的伪代码关联关系

如果还没有理解，则可以将思维放宽一点。当定义变量String a时，这个“a”其实只是一个名称（在第3章中已经说到了常量池），虚拟机需要通过符号表来找到相应的信息，而这种方式正好就像一种K-V结构，底层的处理方式也确实很接近这样，这里的处理方式是显式地使用Map来存放数据，这也是一种实现手段的变通。
现在有了思路，继续回到上面的话题，为了验证前面的推断和理解，来看看createMap方法的细节，如图5-8所示。

图5-8 createMap操作
这段代码是执行一个创建新的Map的操作，并且将第一个值作为这个Map的初始化值，由于这个Map是线程私有的，不可能有另一个线程同时也在对它做put操作，因此这里的赋值和初始化是绝对线程安全的，也同时保证了每一个外部写入的值都将写入到Map对象中。
最后来看看get()、remove()代码，或许看到这里就可以认定我们的理论是正确的，如图5-9所示。

图5-9 get()/remove()方法的代码片段
给我们的感觉是，这样实现是一种技巧，而不是一种技术。
其实是技巧还是技术完全是从某种角度来看的，或者说是从某种抽象层次来看的，如果这段代码在C++中实现，难道就叫技术，不是技巧了吗？当然不是！胖哥认为技术依然是建立在思想和方法基础上的，只是看实现的抽象层次在什么级别。就像在本书中多个地方探讨的一些基础原理一样，我们探讨了它的思想，其实它的实现也是基于某种技巧和手段的，只是对程序封装后就变成了某种语法和API，因此胖哥认为，一旦学会使用技巧思考问题，就学会了通过技巧去看待技术本身。我们应当通过这种设计，学会一种变通和发散的思维，学会理解各种各样的场景，这样便可以积累许多真正的财富，这些财富不是通过某些工具的使用或测试就可以获得的。
ThreadLocal的这种设计很完美吗？
不是很完美，它依然有许多坑，在这里对它容易误导程序员当成传参工具就不再多提了，下面我们来看看它的使用不当会导致什么技术上的问题。
（3）ThreadLocal的坑
通过上面的分析，我们可以认识到ThreadLocal其实是与线程绑定的一个变量，如此就会出现一个问题：如果没有将ThreadLocal内的变量删除（remove）或替换，它的生命周期将会与线程共存。因此，ThreadLocal的一个很大的“坑”就是当使用不当时，导致使用者不知道它的作用域范围。
大家可能认为线程结束后ThreadLocal应该就回收了，如果线程真的注销了确实是这样的，但是事实有可能并非如此，例如在线程池中对线程管理都是采用线程复用的方法（Web容器通常也会采用线程池），在线程池中线程很难结束甚至于永远不会结束，这将意味着线程持续的时间将不可预测，甚至与JVM的生命周期一致。那么相应的ThreadLocal变量的生命周期也将不可预测。
也许系统中定义少量几个ThreadLocal变量也无所谓，因为每次set数据时是用ThreadLocal本身作为Key的，相同的Key肯定会替换原来的数据，原来的数据就可以被释放了，理论上不会导致什么问题。但世事无绝对，如果ThreadLocal中直接或间接包装了集合类或复杂对象，每次在同一个ThreadLocal中取出对象后，再对内容做操作，那么内部的集合类和复杂对象所占用的空间可能会开始膨胀。
抛开代码本身的问题，举一个极端的例子。如果不想定义太多的ThreadLocal变量，就用一个HashMap来存放，这貌似没什么问题。由于ThreadLocal在程序的任何一个地方都可以用得到，在某些设计不当的代码中很难知道这个HashMap写入的源头，在代码中为了保险起见，通常会先检查这个HashMap是否存在，若不存在，则创建一个HashMap写进去；若存在，通常也不会替换掉，因为代码编写者通常会“害怕”因为这种替换会丢掉一些来自“其他地方写入HashMap的数据”，从而导致许多不可预见的问题。
在这样的情况下，HashMap第一次放入ThreadLocal中也许就一直不会被释放，而这个HashMap中可能开始存放许多Key-Value信息，如果业务上存放的Key值在不断变化（例如，将业务的ID作为Key），那么这个HashMap就开始不断变长，并且很可能在每个线程中都有一个这样的HashMap，逐渐地形成了间接的内存泄漏。曾经有很多人吃过这个亏，而且吃亏的时候发现这样的代码可能不是在自己的业务系统中，而是出现在某些二方包、三方包中（开源并不保证没有问题）。
要处理这种问题很复杂，不过首先要保证自己编写的代码是没问题的，要保证没问题不是说我们不去用ThreadLocal，甚至不去学习它，因为它肯定有其应用价值。在使用时要明白ThreadLocal最难以捉摸的是“不知道哪里是源头”（通常是代码设计不当导致的），只有知道了源头才能控制结束的部分，或者说我们从设计的角度要让ThreadLocal的set、remove有始有终，通常在外部调用的代码中使用finally来remove数据，只要我们仔细思考和抽象是可以达到这个目的的。有些是二方包、三方包的问题，对于这些问题我们需要学会的是找到问题的根源后解决，关于二方包、三方包的运行跟踪，可参看第3.7.9节介绍的BTrace工具。
补充：在任何异步程序中（包括异步I/O、非阻塞I/O），ThreadLocal的参数传递是不靠谱的，因为线程将请求发送后，就不再等待远程返回结果继续向下执行了，真正的返回结果得到后，处理的线程可能是另一个。

转载自 并发编程网 - ifeve.com
一道非常棘手的 Java 面试题：i++ 是线程安全的吗？ 相信很多中高级的 Java 面试者都遇到过这个问题，很多对这个不是很清楚的肯定是一脸蒙逼。内心肯定还在质疑，i++ 居然还有线程安全问题？只能说自己了解得不够多，自己的水平有限。