为什么需要并发
并发其实是一种解耦合的策略，它帮助我们把做什么（目标）和什么时候做（时机）分开。这样做可以明显改进应用程序的吞吐量（获得更多的CPU调度时间）和结构（程序有多个部分在协同工作）。
对于并发的误解和正解
最常见的对并发编程的误解有以下这些：
并发总能改进性能（并发在CPU有很多空闲时间时能明显改进程序的性能，但当线程数量较多的时候，线程间频繁的调度切换反而会让系统的性能下降）
编写并发程序无需修改原有的设计（目的与时机的解耦往往会对系统结构产生巨大的影响）
在使用Web或EJB容器时不用关注并发问题（只有了解了容器在做什么，才能更好的使用容器）
下面的这些说法才是对并发客观的认识：
编写并发程序会在代码上增加额外的开销
正确的并发是非常复杂的，即使对于很简单的问题
并发中的缺陷因为不易重现也不容易被发现
并发往往需要对设计策略从根本上进行修改
并发编程的原则和技巧
单一职责原则
分离并发相关代码和其他代码（并发相关代码有自己的开发、修改和调优生命周期）。
限制数据作用域
两个线程修改共享对象的同一字段时可能会相互干扰，导致不可预期的行为，解决方案之一是构造临界区，但是必须限制临界区的数量。
使用数据副本
数据副本是避免共享数据的好方法，复制出来的对象只是以只读的方式对待。Java 5的java.util.concurrent包中增加一个名为CopyOnWriteArrayList的类，它是List接口的子类型，所以你可以认为它是ArrayList的线程安全的版本，它使用了写时复制的方式创建数据副本进行操作来避免对共享数据并发访问而引发的问题。
线程应尽可能独立
让线程存在于自己的世界中，不与其他线程共享数据。
JAVA的线程模型
Java的线程模型建立在抢占式线程调度的基础上，也就是说：
所有线程可以很容易的共享同一进程中的对象。
能够引用这些对象的任何线程都可以修改这些对象。
为了保护数据，对象可以被锁住。
Java 5以前的并发编程
在Java 5以前，可以用synchronized关键字来实现锁的功能，它可以用在代码块和方法上，表示在执行整个代码块或方法之前线程必须取得合适的锁。对于类的非静态方法（成员方法）而言，这意味这要取得对象实例的锁，对于类的静态方法（类方法）而言，要取得类的Class对象的锁，对于同步代码块，程序员可以指定要取得的是哪个对象的锁。
不管是同步代码块还是同步方法，每次只有一个线程可以进入，如果其他线程试图进入（不管是同一同步块还是不同的同步块），JVM会将它们挂起（放入到等锁池中）。这种结构在并发理论中称为临界区（critical section）。这里我们可以对Java中用synchronized实现同步和锁的功能做一个总结：
只能锁定对象，不能锁定基本数据类型
被锁定的对象数组中的单个对象不会被锁定
同步方法可以视为包含整个方法的synchronized(this) { … }代码块
静态同步方法会锁定它的Class对象
内部类的同步是独立于外部类的
synchronized修饰符并不是方法签名的组成部分，所以不能出现在接口的方法声明中
非同步的方法不关心锁的状态，它们在同步方法运行时仍然可以得以运行
synchronized实现的锁是可重入的锁（也叫做递归锁，指的是同一线程外层函数获得锁之后 ，内层递归函数仍然有获取该锁的代码，但不受影响。）。
在JVM内部，为了提高效率，同时运行的每个线程都会有它正在处理的数据的缓存副本，当我们使用synchronzied进行同步的时候，真正被同步的是在不同线程中表示被锁定对象的内存块（副本数据会保持和主内存的同步，现在知道为什么要用同步这个词汇了吧），简单的说就是在同步块或同步方法执行完后，对被锁定的对象做的任何修改要在释放锁之前写回到主内存中；在进入同步块得到锁之后，被锁定对象的数据是从主内存中读出来的，持有锁的线程的数据副本一定和主内存中的数据视图是同步的 。
在Java最初的版本中，就有一个叫volatile的关键字，它是一种简单的同步的处理机制，因为被volatile修饰的变量遵循以下规则：
变量的值在使用之前总会从主内存中再读取出来。对变量值的修改总会在完成之后写回到主内存中。
使用volatile关键字可以在多线程环境下预防编译器不正确的优化假设（编译器可能会将在一个线程中值不会发生改变的变量优化成常量），但只有修改时不依赖当前状态（读取时的值）的变量才应该声明为volatile变量。
不变模式也是并发编程时可以考虑的一种设计。让对象的状态是不变的，如果希望修改对象的状态，就会创建对象的副本并将改变写入副本而不改变原来的对象，这样就不会出现状态不一致的情况，因此不变对象是线程安全的。Java中我们使用频率极高的String类就采用了这样的设计。
Java 5的并发编程
java.util.concurrent包的出现让Java的并发编程有了更多的选择和更好的工作方式。主要包括以下内容：
更好的线程安全的容器
线程池和相关的工具类
可选的非阻塞解决方案
显示的锁和信号量机制
以下示例代码地址: JavaConcurrencyDemo
原子类
Java 5中的java.util.concurrent包下面有一个atomic子包，其中有几个以Atomic打头的类，例如AtomicInteger和AtomicLong。它们利用了现代处理器的特性，可以用非阻塞的方式完成原子操作。
代码见AtomicDemo。
显示锁
基于synchronized关键字的锁机制有以下问题：
锁只有一种类型，而且对所有同步操作都是一样的作用
锁只能在代码块或方法开始的地方获得，在结束的地方释放
线程要么得到锁，要么阻塞，没有其他的可能性
Java 5对锁机制进行了重构，提供了显示的锁，这样可以在以下几个方面提升锁机制：
可以添加不同类型的锁，例如读取锁和写入锁
可以在一个方法中加锁，在另一个方法中解锁
可以使用tryLock方式尝试获得锁，如果得不到锁可以等待、回退或者干点别的事情，当然也可以在超时之后放弃操作
显示的锁都实现了java.util.concurrent.Lock接口，主要有两个实现类：
ReentrantLock - 比synchronized稍微灵活一些的重入锁
ReentrantReadWriteLock - 在读操作很多写操作很少时性能更好的一种重入锁
代码见LockDemo。
CountDownLatch、CyclicBarrier
CountDownLatch是一种简单的同步模式，它让一个线程可以等待一个或多个线程完成它们的工作从而避免对临界资源并发访问所引发的各种问题。
代码见CountDownLatchDemo。
ConcurrentHashMap
ConcurrentHashMap是HashMap在并发环境下的版本，大家可能要问，既然已经可以通过Collections.synchronizedMap获得线程安全的映射型容器，为什么还需要ConcurrentHashMap呢？因为通过Collections工具类获得的线程安全的HashMap会在读写数据时对整个容器对象上锁，这样其他使用该容器的线程无论如何也无法再获得该对象的锁，也就意味着要一直等待前一个获得锁的线程离开同步代码块之后才有机会执行。实际上，HashMap是通过哈希函数来确定存放键值对的桶（桶是为了解决哈希冲突而引入的），修改HashMap时并不需要将整个容器锁住，只需要锁住即将修改的“桶”就可以了。
此外，ConcurrentHashMap还提供了原子操作的方法，如下所示：
putIfAbsent：如果还没有对应的键值对映射，就将其添加到HashMap中。
remove：如果键存在而且值与当前状态相等（equals比较结果为true），则用原子方式移除该键值对映射
replace：替换掉映射中元素的原子操作
CopyOnWriteArrayList
CopyOnWriteArrayList是ArrayList在并发环境下的替代品。CopyOnWriteArrayList通过增加写时复制语义来避免并发访问引起的问题，也就是说任何修改操作都会在底层创建一个列表的副本，也就意味着之前已有的迭代器不会碰到意料之外的修改。这种方式对于不要严格读写同步的场景非常有用，因为它提供了更好的性能。
代码见CopyOnWriteArrayListDemo。
Queue
队列是一个无处不在的美妙概念，它提供了一种简单又可靠的方式将资源分发给处理单元。实现中的并发编程模型很多都依赖队列来实现，因为它可以在线程之间传递工作单元。
Java 5中的BlockingQueue就是一个在并发环境下非常好用的工具，在调用put方法向队列中插入元素时，如果队列已满，它会让插入元素的线程等待队列腾出空间；在调用take方法从队列中取元素时，如果队列为空，取出元素的线程就会阻塞。
代码见QueueDemo与BlockingQueueDemo。
Callable、Future、FutureTask
Callable接口也是一个单方法接口，显然这是一个回调方法，类似于函数式编程中的回调函数。和Runnable接口不同的是Callable接口的回调方法call方法会返回一个对象，这个对象可以用将来时的方式在线程执行结束的时候获得信息。
下面是Future接口的主要方法：
get()：获取结果。如果结果还没有准备好，get方法会阻塞直到取得结果；当然也可以通过参数设置阻塞超时时间。
cancel()：在运算结束前取消。
isDone()：可以用来判断运算是否结束。
代码见CallableDemo。
Semaphore
一个计数信号量。从概念上讲，信号量维护了一个许可集。如有必要，在许可可用前会阻塞每一个 acquire()，然后再获取该许可。每个 release() 添加一个许可，从而可能释放一个正在阻塞的获取者。但是，不使用实际的许可对象，Semaphore 只对可用许可的号码进行计数，并采取相应的行动。拿到信号量的线程可以进入代码，否则就等待。通过acquire()和release()获取和释放访问许可。
解决哲学家进餐问题，代码见SemaphoreDemo。
并发模型
生产者-消费者
一个或多个生产者创建某些工作并将其置于缓冲区或队列中，一个或多个消费者会从队列中获得这些工作并完成之。这里的缓冲区或队列是临界资源。当缓冲区或队列放满的时候，生产这会被阻塞；而缓冲区或队列为空的时候，消费者会被阻塞。生产者和消费者的调度是通过二者相互交换信号完成的。
读者-写者
当存在一个主要为读者提供信息的共享资源，它偶尔会被写者更新，但是需要考虑系统的吞吐量，又要防止饥饿和陈旧资源得不到更新的问题。在这种并发模型中，如何平衡读者和写者是最困难的，当然这个问题至今还是一个被热议的问题，恐怕必须根据具体的场景来提供合适的解决方案而没有那种放之四海而皆准的方法（不像在国内的科研文献中看到的那样）。
哲学家进餐
五个哲学家围坐在一张圆桌周围，每个哲学家面前都有一盘通心粉。由于通心粉很滑，所以需要两把叉子才能夹住。相邻两个盘子之间放有一把叉子如下图所示。哲学家的生活中有两种交替活动时段：即吃饭和思考。当一个哲学家觉得饿了时，他就试图分两次去取其左边和右边的叉子，每次拿一把，但不分次序。如果成功地得到了两把叉子，就开始吃饭，吃完后放下叉子继续思考。
把上面问题中的哲学家换成线程，把叉子换成竞争的临界资源，上面的问题就是线程竞争资源的问题。如果没有经过精心的设计，系统就会出现死锁、活锁、吞吐量下降等问题。
现实中的并发问题基本上都是这三种模型或者是这三种模型的变体。
Java 7的并发编程
Java 7中引入了TransferQueue，它比BlockingQueue多了一个叫transfer的方法，如果接收线程处于等待状态，该操作可以马上将任务交给它，否则就会阻塞直至取走该任务的线程出现。可以用TransferQueue代替BlockingQueue，因为它可以获得更好的性能。
Java 7中还提供了分支/合并（fork/join）框架，它可以实现线程池中任务的自动调度，并且这种调度对用户来说是透明的。为了达到这种效果，必须按照用户指定的方式对任务进行分解，然后再将分解出的小型任务的执行结果合并成原来任务的执行结果。这显然是运用了分治法（divide-and-conquer）的思想。代码见ForkJoinDemo。
伴随着Java 7的到来，Java中默认的数组排序算法已经不再是经典的快速排序（双枢轴快速排序）了，新的排序算法叫TimSort，它是归并排序和插入排序的混合体，TimSort可以通过分支合并框架充分利用现代处理器的多核特性，从而获得更好的性能（更短的排序时间）。
测试并发代码
几个注意事项：
不要将系统的失效归结于偶发事件，就像拉不出屎的时候不能怪地球没有引力。
先让非并发代码工作起来，不要试图同时找到并发和非并发代码中的缺陷。
编写可以在不同配置环境下运行的线程代码。
编写容易调整的线程代码，这样可以调整线程使性能达到最优。
让线程的数量多于CPU或CPU核心的数量，这样CPU调度切换过程中潜在的问题才会暴露出来。
让并发代码在不同的平台上运行。
通过自动化或者硬编码的方式向并发代码中加入一些辅助测试的代码。
总结
与线程同步相关的方法：
wait():使一个线程处于等待（阻塞）状态，并且释放所持有的对象的锁；
sleep():使一个正在运行的线程处于睡眠状态，是一个静态方法，调用此方法要捕捉InterruptedException 异常；
notify():唤醒一个处于等待状态的线程，当然在调用此方法的时候，并不能确切的唤醒某一个等待状态的线程，而是由JVM确定唤醒哪个线程，而且与优先级无关；
notityAll():唤醒所有处入等待状态的线程，注意并不是给所有唤醒线程一个对象的锁，而是让它们竞争；
JDK 1.5通过Lock接口提供了显式(explicit)的锁机制，增强了灵活性以及对线程的协调。Lock接口中定义了加锁（lock()）和解锁(unlock())的方法，同时还提供了newCondition()方法来产生用于线程之间通信的Condition对象；
JDK 1.5还提供了信号量(semaphore)机制，信号量可以用来限制对某个共享资源进行访问的线程的数量。在对资源进行访问之前，线程必须得到信号量的许可（调用Semaphore对象的acquire()方法）；在完成对资源的访问后，线程必须向信号量归还许可（调用Semaphore对象的release()方法）。
来源：林炳河
