高手问答：Java多线程编程实战指南（设计模式篇）--获奖名单公布

南京一号线三山街站=========我是java一年生，最近正在读方腾飞的《JAVA并发编程的艺术》，对多线程有了比较基本的理解，多线程我感觉是对单机多CPU的性能挖掘，而分布式感觉是对集群的充分利用，集群中的每台实例则是对应多线程中每个线程，那么在分布式storm和spark盛行的今天，我们这种新人应该怎么区分出多线程和分布式这两种提高代码性能的优劣势呢？

viscent您好，本人也在从事这方面的开发；有些问题想咨询你一下；最头疼的事情就是开发人员如果去验证并发多线程模块的正确性；感觉自己在开发中对多线程这些无论是借助第三方工具还是一些测试软件都做不到很周全多线程并发的测试；自己也被批了几次；；所以最最重要问题是，visicent老师你能给我一个完美解决方案吗?

我有个问题想咨询一下，简单说多线程的使用是有条件的，如果上下文切换开销非常大的时候，多线程就不如单线程，我主要想了解这个多线程的上下文切换都包括什么操作（我知道的皮毛可能是缓存切换），还有上下文切换的耗时一般什么地方耗时最长容易导致上下文切换慢，是不是解决了上下文切换快慢问题，多线程就可以放心使用呢，感谢博主

viscent是怎么总结出这些模式的？为什么不是更多，或更少？

这些模式是许多人总结出来的。书中收录的都是我使用和在实际项目中接触过的。
所以，有些我了解但是没有具体用过模式，如Leader/Follower，并没有收录进来。以后我有了一定的这些模式的使用经验可能会把它们加进来。
另外，尽管模式具有一定的语言（平台）中立性。但是，有些模式我认为在Java平台中能够发挥的作用有限，不使用这些模式可能反而使代码更加简洁。例如，POSA中收录的Thread Safe Interface模式，其主要意图在于在某些不用锁的情况下（如同一个线程内的组件调用）可以避免锁的开销，而在需要锁的情况下又能使用锁。在Java中基本上语言本身就支持这样的效果，且应用开发人员不需要做额外的事情：其一，Java中的锁是可重入的，这意味着同一个线程多次获取同一个锁并不会导致死锁；其二，Java自从1.6版开始对synchronized关键字的执行进行优化（包括偏向锁Biased Locking、锁粗化Lock Coarsing和锁去除Lock Elimination等），这使得非竞争条件下，锁的消耗大大降低了。也就是说，非竞争的锁的开销和无锁的开销之间的差距已经缩得很小心。

还有的模式其实是我们已经所熟知，并且也无需在其基础上做一些其它的动作。运用其它都是直截了当的。比如Patterns In Java中收录的Single Threaded Execution，其意图就是使某些代码在任一时刻只有一个线程能够执行。大家可能立马想到synchronized。的确如此。所以，这样的模式我并没有收录。

viscent，你好，谢谢你刚才的解答。通过我的学习，在我看来多线程的着眼点是线程的互斥，同步等，而并发编程的着眼点是如何提高多个CPU利用率，现在大数据、云计算挺热门的，那么，在大数据处理过程中，高并发肯定是不可避免的，那么再加上多线程，大数据处理这一块我也不是很懂，是不是会大大增加编程的复杂程度呢？在这方面有没有好的学习建议？
谢谢

银行的营业厅开一个柜台的时候，所有客户只能被分配到这个柜台上。如果同时开几个柜台，那么
所有客户可以被分配到不同的柜台上。这样，从办理业务的客户角度来看，他们等待的时间短了（响应性更好）
。从银行的角度来看，他们同样的时间能够接待的客户更多了（吞吐率变大了）。
这里，单个柜台可以看做单个线程，它可能导致响应性和吞吐率低；而多个柜台可以看做多个线程，它可能
使得响应性和吞吐率增加。
正如我前面的帖子提到的，多线程未必就能提高处理效率，所以我在上面用了“可能”。

《Java多线程编程实战指南（设计模式篇）》答疑开展以来，不少网友提出的问题既有与本书有关的话题，也有Java多线程编程基础知识的相关话题。由于时间关系，对于重复的问题我不逐一回复。还请各位网友参考本总结。这里我将一些与本书相关以及具有代表性的问题提炼下，并附上的我的简要回复。其实，有些问题的回复如果要再深入或者详细，恐怕得写一篇文章，只是时间关系......

《Java多线程编程实战指南（设计模式篇）》答疑总结(陆续更新)：
烦请移步我的博客：http://viscent.iteye.com/

多线程程序的测试的确是个痛点。据我所知，目前还没有一个被普通接受的、有效的多线程测试工具。这点就不像普通代码的单元测试我们可以使用JUnit。我分享下我们的经验——基于上述考虑，我们更倾向于依赖与以下几个方面：

• 更好的设计

多线程的许多问题其实是由于多个线程共享可变变量（Shared Mutable Variable）造成的。不幸的是，由此造成的问题（通常是代码编写不正确，比如忘记使用同步）往往很难再现。比如，可见性问题、重排序问题。更不幸的是，这类问题一旦出现可能导致严重的后果。因此，从设计的角度来说，某些情况下我们其实有更好的选择，那就是选择不共享变量或者共享状态不可变的变量。这样，也就自然而然避免了许多与多线程相关的问题。本书第3章和第10章有这样的实战案例。

• Code Review和静态检查

基于多线程问题的复杂性，我认为Code Review是发现多线程相关Bug的最可靠的一种方法。其缺点是可能比较耗时间，并且对于新手而言，他可能很难通过该途径发现问题。不过，我们可以接着静态检查工具，比如FindBugs可以协助我们发现相关问题。对于一些常见的多线程Bug，静态检查工具通常也能够帮我们找出来。比如下面的代码：

public void someMethod(){
synchronized(this){
       if(!responseReceived){
　　wait(10000);
       }
  }
}

静态检查工具可以告诉我们，上面的wait调用没有放在循环内。

• 负载/压力测试

这种测试不仅仅可以用于评估程序的性能，也可以帮助我们发现一些多线程的问题。我带的项目组，每次迭代开发的时候负载/压力测试是必做的。我甚至鼓励开发人员自己做负载/开发测试。