编写优质的并发代码是一件难度极高的事情。Java语言从第一版本开始内置了对多线程的支持，这一点在当年是非常了不起的，但是当我们对并发编程有了更深刻的认识和更多的实践后，实现并发编程就有了更多的方案和更好的选择。本文是对并发编程的一点总结和思考，
为什么需要并发
并发其实是一种解耦合的策略，它帮助我们把做什么(目标)和什么时候做(时机)分开。这样做可以明显改进应用程序的吞吐量(获得更多的CPU调度时间)和结构(程序有多个部分在协同工作)。做过Java Web开发的人都知道，Java Web中的Servlet程序在Servlet容器的支持下采用单实例多线程的工作模式，Servlet容器帮助你处理了并发请求的问题。
误解和正解
最常见的对并发编程的误解有以下这些：
A. 并发总能改进性能。(真相：并发在CPU有很多空闲时间时能明显改进程序的性能，但当线程数量较多的时候，线程间频繁的调度切换反而会让系统的性能下降)
B. 编写并发程序无需修改原有的设计。(真相：目的与时机的解耦往往会对系统结构产生巨大的影响)
C. 在使用Web或EJB容器时不用关注并发问题。(真相：只有了解了容器在做什么，才能更好的使用容器)
下面的这些说法才是对并发编程比较客观的认识：
A. 编写并发程序会在代码上增加额外的开销。
B. 正确的并发是非常复杂的，即使对于很简单的问题。
C. 并发中的缺陷因为不易重现也不容易被发现。
D. 并发往往需要对设计策略从根本上进行修改。
并发编程的原则和技巧
1. 单一职责原则：分离并发相关代码和其他代码(并发相关代码有自己的开发、修改和调优生命周期)。
2. 限制数据作用域：两个线程修改共享对象的同一字段时可能会相互干扰，导致不可预期的行为，解决方案之一是构造临界区，但是必须限制临界区的数量。
3. 使用数据副本：数据副本是避免共享数据的好方法，复制出来的对象只是以只读的方式对待。Java 5的urrent包中增加一个名为CopyOnWriteArrayList的类，它是List接口的子类型，所以你可以认为它是ArrayList的线程安全的版本，它使用了写时复制的方式创建数据副本进行操作来避免对共享数据并发访问而引发的问题。
4. 线程应尽可能独立：让线程存在于自己的世界中，不与其他线程共享数据。有过Java Web开发经验的人都知道，Servlet就是以单实例多线程的方式工作，和每个请求相关的数据都是通过Servlet子类的service方法(或者是doGet或doPost方法)的参数传入的。只要Servlet中的代码只使用局部变量，Servlet就不会导致同步问题。Spring MVC的控制器也是这么做的，从请求中获得的对象都是以方法的参数传入而不是作为类的成员，很明显Struts 2的做法就正好相反，因此Struts 2中作为控制器的Action类都是每个请求对应一个实例。
下面的这些说法才是对并发客观的认识：
-编写并发程序会在代码上增加额外的开销 -正确的并发是非常复杂的，即使对于很简单的问题 -并发中的缺陷因为不易重现也不容易被发现
-并发往往需要对设计策略从根本上进行修改并发编程的原则和技巧 单一职责原则 分离并发相关代码和其他代码(并发相关代码有自己的开发、修改和调优生命周期)。限制数据作用域 两个线程修改共享对象的同一字段时可能会相互干扰，导致不可预期的行为，解决方案之一是构造临界区，但是必须限制临界区的数量。使用数据副本 数据副本是避免共享数据的好方法，复制出来的对象只是以只读的方式对待。
Java 5的urrent包中增加一个名为CopyOnWriteArrayList的类，它是List接口的子类型，所以你可以认为它是ArrayList的线程安全的版本，它使用了写时复制的方式创建数据副本进行操作来避免对共享数据并发访问而引发的问题。线程应尽可能独立 让线程存在于自己的世界中，不与其他线程共享数据。有过Java Web开发经验的人都知道，Servlet就是以单实例多线程的方式工作，和每个请求相关的数据都是通过Servlet子类的service方法(或者是doGet或doPost方法)的参数传入的。只要Servlet中的代码只使用局部变量，Servlet就不会导致同步问题。
springMVC的控制器也是这么做的，从请求中获得的对象都是以方法的参数传入而不是作为类的成员，很明显Struts 2的做法就正好相反，因此Struts 2中作为控制器的Action类都是每个请求对应一个实例。 Java 5以前的并发编程 Java的线程模型建立在抢占式线程调度的基础上，也就是说： 所有线程可以很容易的共享同一进程中的对象。能够引用这些对象的任何线程都可以修改这些对象。为了保护数据，对象可以被锁住。 Java基于线程和锁的并发过于底层，而且使用锁很多时候都是很万恶的，因为它相当于让所有的并发都变成了排队等待。
在Java 5以前，可以用synchronized关键字来实现锁的功能，它可以用在代码块和方法上，表示在执行整个代码块或方法之前线程必须取得合适的锁。对于类的非静态方法(成员方法)而言，这意味这要取得对象实例的锁，对于类的静态方法(类方法)而言，要取得类的Class对象的锁，对于同步代码块，程序员可以指定要取得的是那个对象的锁。 不管是同步代码块还是同步方法，每次只有一个线程可以进入，如果其他线程试图进入(不管是同一同步块还是不同的同步块)，JVM会将它们挂起(放入到等锁池中)。这种结构在并发理论中称为临界区(critical section)。
这里我们可以对Java中用synchronized实现同步和锁的功能做一个总结： 只能锁定对象，不能锁定基本数据类型被锁定的对象数组中的单个对象不会被锁定同步方法可以视为包含整个方法的synchronized(this) { … }代码块静态同步方法会锁定它的Class对象内部类的同步是独立于外部类的 synchronized修饰符并不是方法签名的组成部分，所以不能出现在接口的方法声明中非同步的方法不关心锁的状态，它们在同步方法运行时仍然可以得以运行 synchronized实现的锁是可重入的锁。在JVM内部，为了提高效率，同时运行的每个线程都会有它正在处理的数据的缓存副本，当我们使用synchronzied进行同步的时候，真正被同步的是在不同线程中表示被锁定对象的内存块(副本数据会保持和主内存的同步，现在知道为什么要用同步这个词汇了吧)，简单的说就是在同步块或同步方法执行完后，对被锁定的对象做的任何修改要在释放锁之前写回到主内存中;在进入同步块得到锁之后，被锁定对象的数据是从主内存中读出来的，持有锁的线程的数据副本一定和主内存中的数据视图是同步的 。 在Java最初的版本中，就有一个叫Volatile的关键字，它是一种简单的同步的处理机制，因为被volatile修饰的变量遵循以下规则： 变量的值在使用之前总会从主内存中再读取出来。对变量值的修改总会在完成之后写回到主内存中。使用volatile关键字可以在多线程环境下预防编译器不正确的优化假设(编译器可能会将在一个线程中值不会发生改变的变量优化成常量)，但只有修改时不依赖当前状态(读取时的值)的变量才应该声明为volatile变量。
书香门第
