java必谈多线程（转）

原文地址：http://406657836.iteye.com/blog/1894307

 

程序语言作为开发软件的工具，与电脑沟通交流的工具。每个人都有选择工具的理由。我选择java的理由是：强规范，保证了很多低级错误，难以发觉的错误在编译期被检查；严格的内存管理，对内存的访问java是有严格的规范的，它可以防止数组下标越界，错误的内存访问；高性能的垃圾回收器，java在cms并发收集器出现后性能上了一个台阶，而且java虚拟机还在不断的发展进步，java的性能也会得到极大的提高，java的性能问题逐渐成了过去式；多线程，多线程是java优势所在，java语言在这方面也是下了很大的功夫，使java的多线程性能和安全性都如此强大。这些原因使我非常热爱在java语言上的学习，研究。 

本文主要介绍java多线程方面的知识。正如很多java程序员知道的那样，java多线程确实涉及到很多注意事项。这篇博文主要是引出一些话题，对他们进行讨论。如果要深入讨论的话，每一个话题都足以用几篇博文来讲解。下面是将要出现的一些话题： 

1，为什么要多线程(多线程的优势) 

2，多线程有什么问题(多线程要解决的问题) 

3，java对多线程的规范(java解决多线程问题对jvm作出的规范) 

4，java解决多线程问题的手段，包括(synchronized,ReentrantLock,volatile,final,ThreadLocal,栈封闭,JUC技术等)


关于第一个话题： 

要使用多线程的理由有很多，总体来说有如下(可能不全): 

1,尽量利用系统资源，减少任务完成时间。(如，在IO阻塞的时候可以让出cpu,分布式运算 mapreduce) 

2,多任务系统，有些事情需要并行执行。(如，需要响应用户中断请求) 

3,需要同时为更多人提供服务，不能因为一个长任务完全占用系统资源，使一些短任务也不能服务。(如，web服务器) 

4,一台服务器可以有很多cpu(单个cpu也可以支持超线程)，所以多线程是必然的趋势。 


关于第二个话题： 

多线程下确实有很多不确定性。也很难像串行化执行那么调试程序。问题可能要一定的运行时间，一定的操作顺序才能产生。所以很多程序员在回避这个问题，很害怕去使用多线程。所以多线程要解决的第一个问题就是心理畏惧问题。对于技术上，多线程主要有两个问题要解决。这也是开发多线程程序时一定要思考的问题。 

1,共享数据的可见性(一个线程写入的数据，何时对于其他线程可见)。 

2,共享资源的竞争问题(多个线程同时请求一个资源，谁先谁后，如计数问题，转账问题等)。 

注意这里都有共享二字，也就是需要在多线程中同时操作资源才可能出问题。下面讨论下这两个问题产生的原因和情景。 

对于可见性问题： 

cpu的执行速度快的惊人，以致于计算机执行速度的瓶颈在IO上。所以除了cpu寄存器缓存外，还有L1 ，L2——在cpu上的独立缓存，L3——同一个cpu槽内共享的缓存。然后才是主存,磁盘,网络等。在cpu需要访问数据时，会依次沿着上面的缓存读写数据。就拿写来说，假设一份数据在主存中，它会被一层层加载到寄存器缓存中来，假设cpu0要改变这份数据的值，会先写到寄存器缓存中，这时候数据并不会马上去修改主存中的数据，如果第二个cpu又来读这份数据，它不会里面读到之前的改变值而是读到一个"脏"值。也就是第一个操作对于第二个操作不可见。而且这时候第二个cpu可能根据条件判断，对这个值做出一些处理。由于不可见，会引发判断是失效，丢失的更新等等问题。不可见问题还有可能由重排序引起。 

对于资源竞争问题： 

资源竞争问题其实很好理解，如对一个变量计数。由于计数要分为读取，改变(依赖原来值做修改)，替换三个步骤。如果多个线程不加任何限制的执行这个三个步骤，就会使其它步骤失效。还有HashMap扩容问题，打印机这些只能独占资源等等。这些都是资源竞争的一些问题。资源竞争问题远没有这么简单，特别是在高并发下，还可能引发一些硬件层面的问题。这个也是多线程的难点。资源竞争问题也可能由重排序引起。 

关于第三个话题： 

java对多线程提出来了自己的一套JMM模型。这个模型主要是对可见性约定——happens-before原则。happens-before有如下约定： 


（1）同一个线程中的每条指令都happens-before于出现在其后的任何一个指令。 

（2）对一个监视器的解锁happens-before于每一个后续对同一个监视器的加锁。 

（3）对volatile字段的写入操作happens-before于后续这个字段的读操作。 

（4）对于final修饰的变量，对它的构造happens-before于对它的第一次访问之前。 

（5）Thread.start()的调用会happens-before于启动线程里面的动作。 

（6）Thread中的所有动作都happens-before于其他线程检查到此线程结束或者Thread.join（）中返回或者Thread.isAlive()==false。 

（7）一个线程A调用另一个另一个线程B的interrupt（）都happens-before于线程A发现B被A中断（B抛出异常或者A检测到B的isInterrupted（）或者interrupted()）。 

（8）一个对象构造函数的结束happens-before与该对象的finalizer的开始 

（9）如果A动作happens-before于B动作，而B动作happens-before与C动作，那么A动作happens-before于C动作 

这些happens-before的约定解决了共享变量的可见性问题。对于共享资源竞争性主要是靠有锁的synchronized和lock，和无锁的cas操作保证。 

关于第四个话题: 

被final修饰的变量，是不可变对象(如果是一个引用类型，只是引用不可变，其值任然可变)。所以通过final修饰共享变量，可以大大减少多线程访问的复杂度。因为不可变对象一定是线程安全的。构造不可变对象是一个好的编程习惯。 

栈封闭，其实就是说没有共享变量，把所有变量的分配都在本线程的方法栈内使用。不传递给其他线程使用。这其实是回避了多线程共享问题，很多时候我们仍然需要共享的。 

ThreadLocal,这是另一个回避多线程共享变量的技术(只对本线程共享)。它把对象绑定到线程本地，Thread上的ThreadLocalMap中。这是一个弱键引用的map，键是ThreadLocal,value是具体本地线程共享的对象。所以这样的对象有两种方式被回收。第一ThreadLocal实例失去了强引用，在gc时可能会把它回收，第二这个线程失去了强引用，随着线程的回收而回收。所以ThreadLocal是不会内存溢出的。使用remove去移除不需要的变量是一种好习惯。如果线程长时间运行ThreadLocal通常也是不会失去强引用的，所以这里的内容得不到回收。 

volatile变量主要是对可见性的约束，即它的写入总能立即被下一个读取的线程看到。但是它不保证原子操作。 

synchronized是在对象或类上的内置锁。在synchronized作用域内的代码不能被重排序，并且读取共享变量能够看到它的最新状态，写入共享变量能够对持有这个锁的其它对象立即可见。 

ReentrantLock提供了与synchronized相同的功能。它们的主要区别是 

1,ReentrantLock必须自己释放锁。通常在finally释放。 

2,ReentrantLock可以通过参数控制多线程访问的公平性。 

3,ReentrantLock可以通过tryLock(),非阻塞的获得锁,也可以在指定等待时间内获得锁。synchronized一旦进入锁竞争就一定得等到锁，所以更容易产生死锁。 

4,ReentrantLock可以响应中断，而synchronized是无法响应中断的。这一点很重要！一个好的线程设计都需要响应中断。 

JUC的包很多主要是一些多线程工具。这里主要说下cas操作。像AtomicXXXX主要是利用cas操作，而不是锁。所以它的效率会高于有锁的同步。cas操作又主要是又cpu的硬件支持。JUC的内容很多在这里不单独讨论，有兴趣的同学可以看这篇博客，http://blog.csdn.net/xieyuooo/article/details/8594713 


关于多线程的讨论暂时就到此了，如有任何纰漏还请多多指出，谢谢！