本篇内容主要讲解“Java多线程发展史是怎样的”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“Java多线程发展史是怎样的”吧!
JDK 1.0
1996年1月的JDK1.0版本，从一开始就确立了Java最基础的线程模型，并且，这样的线程模型再后续的修修补补中，并未发生实质性的变更，可以说是一个具有传承性的良好设计。
抢占式和协作式是两种常见的进程/线程调度方式，操作系统非常适合使用抢占式方式来调度它的进程，它给不同的进程分配时间片，对于长期无响应的进程，它有能力剥夺它的资源，甚至将其强行停止（如果采用协作式的方式，需要进程自觉、主动地释放资源，也许就不知道需要等到什么时候了）。Java语言一开始就采用协作式的方式，并且在后面发展的过程中，逐步废弃掉了粗暴的stop/resume/suspend这样的方法，它们是违背协作式的不良设计，转而采用wait/notify/sleep这样的两边线程配合行动的方式。
一种线程间的通信方式是使用中断：
public class InterruptCheck extends Thread { @Override public void run() { System.out.println("start"); while (true) if (Thread.currentThread().isInterrupted()) break; System.out.println("while exit"); } public static void main(String[] args) { Thread thread = new InterruptCheck(); thread.start(); try { sleep(2000); } catch (InterruptedException e) { } thread.interrupt(); } }这是中断的一种使用方式，看起来就像是一个标志位，线程A设置这个标志位，线程B时不时地检查这个标志位。另外还有一种使用中断通信的方式，如下：
public class InterruptWait extends Thread { public static Object lock = new Object(); @Override public void run() { System.out.println("start"); synchronized (lock) { try { lock.wait(); } catch (InterruptedException e) { System.out.println(Thread.currentThread().isInterrupted()); Thread.currentThread().interrupt(); // set interrupt flag again System.out.println(Thread.currentThread().isInterrupted()); e.printStackTrace(); } } } public static void main(String[] args) { Thread thread = new InterruptWait(); thread.start(); try { sleep(2000); } catch (InterruptedException e) { } thread.interrupt(); } }在这种方式下，如果使用wait方法处于等待中的线程，被另一个线程使用中断唤醒，于是抛出InterruptedException，同时，中断标志清除，这时候我们通常会在捕获该异常的地方重新设置中断，以便后续的逻辑通过检查中断状态来了解该线程是如何结束的。
在比较稳定的JDK 1.0.2版本中，已经可以找到Thread和ThreadUsage这样的类，这也是线程模型中最核心的两个类。整个版本只包含了这样几个包：java.io、 java.util、java.net、java.awt和java.applet，所以说Java从一开始这个非常原始的版本就确立了一个持久的线程模型。
值得一提的是，在这个版本中，原子对象AtomicityXXX已经设计好了，这里给出一个例子，说明i++这种操作时非原子的，而使用原子对象可以保证++操作的原子性：
import java.util.concurrent.atomic.AtomicInteger; public class Atomicity { private static volatile int nonAtomicCounter = 0; private static volatile AtomicInteger atomicCounter = new AtomicInteger(0); private static int times = 0; public static void caculate() { times++; for (int i = 0; i < 1000; i++) { new Thread(new Runnable() { @Override public void run() { nonAtomicCounter++; atomicCounter.incrementAndGet(); } }).start(); } try { Thread.sleep(1000); } catch (InterruptedException e) { } } public static void main(String[] args) { caculate(); while (nonAtomicCounter == 1000) { nonAtomicCounter = 0; atomicCounter.set(0); caculate(); } System.out.println("Non-atomic counter: " + times + ":" + nonAtomicCounter); System.out.println("Atomic counter: " + times + ":" + atomicCounter); } }上面这个例子你也许需要跑几次才能看到效果，使用非原子性的++操作，结果经常小于1000。
对于锁的使用，网上可以找到各种说明，但表述都不够清晰。请看下面的代码：
public class Lock { private static Object o = new Object(); static Lock lock = new Lock(); // lock on dynamic method public synchronized void dynamicMethod() { System.out.println("dynamic method"); sleepSilently(2000); } // lock on static method public static synchronized void staticMethod() { System.out.println("static method"); sleepSilently(2000); } // lock on this public void thisBlock() { synchronized (this) { System.out.println("this block"); sleepSilently(2000); } } // lock on an object public void objectBlock() { synchronized (o) { System.out.println("dynamic block"); sleepSilently(2000); } } // lock on the class public static void classBlock() { synchronized (Lock.class) { System.out.println("static block"); sleepSilently(2000); } } private static void sleepSilently(long millis) { try { Thread.sleep(millis); } catch (InterruptedException e) { e.printStackTrace(); } } public static void main(String[] args) { // object lock test new Thread() { @Override public void run() { lock.dynamicMethod(); } }.start(); new Thread() { @Override public void run() { lock.thisBlock(); } }.start(); new Thread() { @Override public void run() { lock.objectBlock(); } }.start(); sleepSilently(3000); System.out.println(); // class lock test new Thread() { @Override public void run() { lock.staticMethod(); } }.start(); new Thread() { @Override public void run() { lock.classBlock(); } }.start(); } }上面的例子可以反映对一个锁竞争的现象，结合上面的例子，理解下面这两条，就可以很容易理解synchronized关键字的使用：
非静态方法使用synchronized修饰，相当于synchronized(this)。
静态方法使用synchronized修饰，相当于synchronized(Lock.class)。
JDK 1.2
1998年年底的JDK1.2版本正式把Java划分为J2EE/J2SE/J2ME三个不同方向。在这个版本中，Java试图用Swing修正在 AWT中犯的错误，例如使用了太多的同步。可惜的是，Java本身决定了AWT还是Swing性能和响应都难以令人满意，这也是Java桌面应用难以比及其服务端应用的一个原因，在IBM后来的SWT，也不足以令人满意，JDK在这方面到JDK 1.2后似乎反省了自己，停下脚步了。值得注意的是，JDK高版本修复低版本问题的时候，通常遵循这样的原则：
向下兼容。所以往往能看到很多重新设计的新增的包和类，还能看到deprecated的类和方法，但是它们并不能轻易被删除。
严格遵循JLS（Java Language Specification），并把通过的新JSR（Java Specification Request）补充到JLS中，因此这个文档本身也是向下兼容的，后面的版本只能进一步说明和特性增强，对于一些最初扩展性比较差的设计，也会无能为力。这个在下文中关于ReentrantLock的介绍中也可以看到。
在这个版本中，正式废除了这样三个方法：stop()、suspend()和resume()。下面我就来介绍一下，为什么它们要被废除：
public class Stop extends Thread { @Override public void run() { try { while (true) ; } catch (Throwable e) { e.printStackTrace(); } } public static void main(String[] args) { Thread thread = new Stop(); thread.start(); try { sleep(1000); } catch (InterruptedException e) { } thread.stop(new Exception("stop")); // note the stack trace } }从上面的代码你应该可以看出两件事情：
使用stop来终止一个线程是不讲道理、极其残暴的，不论目标线程在执行任何语句，一律强行终止线程，最终将导致一些残缺的对象和不可预期的问题产生。
被终止的线程没有任何异常抛出，你在线程终止后找不到任何被终止时执行的代码行，或者是堆栈信息（上面代码打印的异常仅仅是main线程执行stop语句的异常而已，并非被终止的线程）。
很难想象这样的设计出自一个连指针都被废掉的类型安全的编程语言，对不对？再来看看suspend的使用，有引起死锁的隐患：
public class Suspend extends Thread { @Override public void run() { synchronized (this) { while (true) ; } } public static void main(String[] args) { Thread thread = new Suspend(); thread.start(); try { sleep(1000); } catch (InterruptedException e) { } thread.suspend(); synchronized (thread) { // dead lock System.out.println("got the lock"); thread.resume(); } } }从上面的代码可以看出，Suspend线程被挂起时，依然占有锁，而当main线程期望去获取该线程来唤醒它时，彻底瘫痪了。由于suspend在这里是无期限限制的，这会变成一个彻彻底底的死锁。
相反，看看这三个方法的改进品和替代品：wait()、notify()和sleep()，它们令线程之间的交互就友好得多：
public class Wait extends Thread { @Override public void run() { System.out.println("start"); synchronized (this) { // wait/notify/notifyAll use the same // synchronization resource try { this.wait(); } catch (InterruptedException e) { e.printStackTrace(); // notify won't throw exception } } } public static void main(String[] args) { Thread thread = new Wait(); thread.start(); try { sleep(2000); } catch (InterruptedException e) { } synchronized (thread) { System.out.println("Wait() will release the lock!"); thread.notify(); } } }在wait和notify搭配使用的过程中，注意需要把它们锁定到同一个资源上（例如对象a），即：
一个线程中synchronized(a)，并在同步块中执行a.wait()
另一个线程中synchronized(a)，并在同步块中执行a.notify()
再来看一看sleep方法的使用，回答下面两个问题：
和wait比较一下，为什么sleep被设计为Thread的一个静态方法（即只让当前线程sleep）？
为什么sleep必须要传入一个时间参数，而不允许不限期地sleep？
如果我前面说的你都理解了，你应该能回答这两个问题。
public class Sleep extends Thread { @Override public void run() { System.out.println("start"); synchronized (this) { // sleep() can use (or not) any synchronization resource try { this.sleep(10000); } catch (InterruptedException e) { e.printStackTrace(); // notify won't throw exception } } } public static void main(String[] args) { Thread thread = new Sleep(); thread.start(); try { sleep(2000); } catch (InterruptedException e) { } synchronized (thread) { System.out.println("Has sleep() released the lock!"); thread.notify(); } } }在这个JDK版本中，引入线程变量ThreadLocal这个类：
每一个线程都挂载了一个ThreadLocalMap。ThreadLocal这个类的使用很有意思，get方法没有key传入，原因就在于这个 key就是当前你使用的这个ThreadLocal它自己。ThreadLocal的对象生命周期可以伴随着整个线程的生命周期。因此，倘若在线程变量里存放持续增长的对象（最常见是一个不受良好管理的map），很容易导致内存泄露。
public class ThreadLocalUsage extends Thread { public User user = new User(); public User getUser() { return user; } @Override public void run() { this.user.set("var1"); while (true) { try { sleep(1000); } catch (InterruptedException e) { } System.out.println(this.user.get()); } } public static void main(String[] args) { ThreadLocalUsage thread = new ThreadLocalUsage(); thread.start(); try { sleep(4000); } catch (InterruptedException e) { } thread.user.set("var2"); } } class User { private static ThreadLocal<Object> enclosure = new ThreadLocal<Object>(); // is it must be static? public void set(Object object) { enclosure.set(object); } public Object get() { return enclosure.get(); } }上面的例子会一直打印var1，而不会打印var2，就是因为不同线程中的ThreadLocal是互相独立的。
用jstack工具可以找到锁相关的信息，如果线程占有锁，但是由于执行到wait方法时处于wait状态暂时释放了锁，会打印waiting on的信息：
"Thread-0" prio=6 tid=0x02bc4400 nid=0xef44 in Object.wait() [0x02f0f000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x22a7c3b8> (a Wait) at java.lang.Object.wait(Object.java:485) at Wait.run(Wait.java:8) - locked <0x22a7c3b8> (a Wait)如果程序持续占有某个锁（例如sleep方法在sleep期间不会释放锁），会打印locked的信息：
"Thread-0" prio=6 tid=0x02baa800 nid=0x1ea4 waiting on condition [0x02f0f000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at Wait.run(Wait.java:8) - locked <0x22a7c398> (a Wait)而如果是线程希望进入某同步块，而在等待锁的释放，会打印waiting to的信息：
"main" prio=6 tid=0x00847400 nid=0xf984 waiting for monitor entry [0x0092f000] java.lang.Thread.State: BLOCKED (on object monitor) at Wait.main(Wait.java:23) - waiting to lock <0x22a7c398> (a Wait)JDK 1.4
在2002年4月发布的JDK1.4中，正式引入了NIO。JDK在原有标准IO的基础上，提供了一组多路复用IO的解决方案。
通过在一个Selector上挂接多个Channel，通过统一的轮询线程检测，每当有数据到达，触发监听事件，将事件分发出去，而不是让每一个channel长期消耗阻塞一个线程等待数据流到达。所以，只有在对资源争夺剧烈的高并发场景下，才能见到NIO的明显优势。
相较于面向流的传统方式这种面向块的访问方式会丢失一些简易性和灵活性。下面给出一个NIO接口读取文件的简单例子（仅示意用）：
import java.io.FileInputStream; import java.io.IOException; import java.nio.ByteBuffer; import java.nio.channels.FileChannel; public class NIO { public static void nioRead(String file) throws IOException { FileInputStream in = new FileInputStream(file); FileChannel channel = in.getChannel(); ByteBuffer buffer = ByteBuffer.allocate(1024); channel.read(buffer); byte[] b = buffer.array(); System.out.println(new String(b)); channel.close(); } }JDK 5.0
2004年9月起JDK 1.5发布，并正式更名到5.0。有个笑话说，软件行业有句话，叫做“不要用3.0版本以下的软件”，意思是说版本太小的话往往软件质量不过关——但是按照这种说法，JDK的原有版本命名方式得要到啥时候才有3.0啊，于是1.4以后通过版本命名方式的改变直接升到5.0了。
JDK 5.0不只是版本号命名方式变更那么简单，对于多线程编程来说，这里发生了两个重大事件，JSR 133和JSR 166的正式发布。
JSR 133
JSR 133重新明确了Java内存模型，事实上，在这之前，常见的内存模型包括连续一致性内存模型和先行发生模型。
对于连续一致性模型来说，程序执行的顺序和代码上显示的顺序是完全一致的。这对于现代多核，并且指令执行优化的CPU来说，是很难保证的。而且，顺序一致性的保证将JVM对代码的运行期优化严重限制住了。
但是JSR 133指定的先行发生（Happens-before）使得执行指令的顺序变得灵活：
在同一个线程里面，按照代码执行的顺序（也就是代码语义的顺序），前一个操作先于后面一个操作发生
对一个monitor对象的解锁操作先于后续对同一个monitor对象的锁操作
对volatile字段的写操作先于后面的对此字段的读操作
对线程的start操作（调用线程对象的start()方法）先于这个线程的其他任何操作
一个线程中所有的操作先于其他任何线程在此线程上调用 join()方法
如果A操作优先于B，B操作优先于C，那么A操作优先于C
而在内存分配上，将每个线程各自的工作内存（甚至包括）从主存中独立出来，更是给JVM大量的空间来优化线程内指令的执行。主存中的变量可以被拷贝到线程的工作内存中去单独执行，在执行结束后，结果可以在某个时间刷回主存：
但是，怎样来保证各个线程之间数据的一致性？JLS给的办法就是，默认情况下，不能保证任意时刻的数据一致性，但是通过对 synchronized、volatile和final这几个语义被增强的关键字的使用，可以做到数据一致性。要解释这个问题，不如看一看经典的 DCL（Double Check Lock）问题：
public class DoubleCheckLock { private volatile static DoubleCheckLock instance; // Do I need add "volatile" here? private final Element element = new Element(); // Should I add "final" here? Is a "final" enough here? Or I should use "volatile"? private DoubleCheckLock() { } public static DoubleCheckLock getInstance() { if (null == instance) synchronized (DoubleCheckLock.class) { if (null == instance) instance = new DoubleCheckLock(); //the writes which initialize instance and the write to the instance field can be reordered without "volatile" } return instance; } public Element getElement() { return element; } } class Element { public String name = new String("abc"); }在上面这个例子中，如果不对instance声明的地方使用volatile关键字，JVM将不能保证getInstance方法获取到的 instance是一个完整的、正确的instance，而volatile关键字保证了instance的可见性，即能够保证获取到当时真实的 instance对象。
但是问题没有那么简单，对于上例中的element而言，如果没有volatile和final修饰，element里的name也无法在前文所述的instance返回给外部时的可见性。如果element是不可变对象，使用final也可以保证它在构造方法调用后的可见性。
对于volatile的效果，很多人都希望有一段简短的代码能够看到，使用volatile和不使用volatile的情况下执行结果的差别。可惜这其实并不好找。这里我给出这样一个不甚严格的例子：
public class Volatile { public static void main(String[] args) { final Volatile volObj = new Volatile(); Thread t2 = new Thread() { public void run() { while (true) { volObj.check(); } } }; t2.start(); Thread t1 = new Thread() { public void run() { while (true) { volObj.swap(); } } }; t1.start(); } boolean boolValue;// use volatile to print "WTF!" public void check() { if (boolValue == !boolValue) System.out.println("WTF!"); } public void swap() { try { Thread.sleep(100); } catch (InterruptedException e) { e.printStackTrace(); } boolValue = !boolValue; } }代码中存在两个线程，一个线程通过一个死循环不断在变换boolValue的取值；另一个线程每100毫秒执行 “boolValue==!boolValue”，这行代码会取两次boolValue，可以想象的是，有一定概率会出现这两次取boolValue结果不一致的情况，那么这个时候就会打印“WTF!”。
但是，上面的情况是对boolValue使用volatile修饰保证其可见性的情况下出现的，如果不对boolValue使用volatile修饰，运行时就一次不会出现（起码在我的电脑上）打印“WTF!”的情形，换句话说，这反而是不太正常的，我无法猜测JVM做了什么操作，基本上唯一可以确定的是，没有用volatile修饰的时候，boolValue在获取的时候，并不能总取到最真实的值。
JSR 166
JSR 166的贡献就是引入了java.util.concurrent这个包。前面曾经讲解过AtomicXXX类这种原子类型，内部实现保证其原子性的其实是通过一个compareAndSet(x,y)方法（CAS），而这个方法追踪到最底层，是通过CPU的一个单独的指令来实现的。这个方法所做的事情，就是保证在某变量取值为x的情况下，将取值x替换为y。在这个过程中，并没有任何加锁的行为，所以一般它的性能要比使用synchronized高。
Lock-free算法就是基于CAS来实现原子化“set”的方式，通常有这样两种形式：
import java.util.concurrent.atomic.AtomicInteger; public class LockFree { private AtomicInteger max = new AtomicInteger(); // type A public void setA(int value) { while (true) { // 1.circulation int currentValue = max.get(); if (value > currentValue) { if (max.compareAndSet(currentValue, value)) // 2.CAS break; // 3.exit } else break; } } // type B public void setB(int value) { int currentValue; do { // 1.circulation currentValue = max.get(); if (value <= currentValue) break; // 3.exit } while (!max.compareAndSet(currentValue, value)); // 2.CAS } }不过，对CAS的使用并不总是正确的，比如ABA问题。我用下面这样一个栈的例子来说明：
线程t1先查看了一下栈的情况，发现栈里面有A、B两个元素，栈顶是A，这是它所期望的，它现在很想用CAS的方法把A pop出去。
这时候线程t2来了，它pop出A、B，又push一个C进去，再把A push回去，这时候栈里面存放了A、C两个元素，栈顶还是A。
t1开始使用CAS：head.compareAndSet(A,B)，把A pop出去了，栈里就剩下B了，可是这时候其实已经发生了错误，因为C丢失了。
为什么会发生这样的错误？因为对t1来说，它两次都查看到栈顶的A，以为期间没有发生变化，而实际上呢？实际上已经发生了变化，C进来、B出去了，但是t1它只看栈顶是A，它并不知道曾经发生了什么。
那么，有什么办法可以解决这个问题呢？
最常见的办法是使用一个计数器，对这个栈只要有任何的变化，就触发计数器+1，t1在要查看A的状态，不如看一下计数器的情况，如果计数器没有变化，说明期间没有别人动过这个栈。JDK 5.0里面提供的AtomicStampedReference就是起这个用的。
使用immutable对象的拷贝（比如CopyOnWrite）也可以实现无锁状态下的并发访问。举一个简单的例子，比如有这样一个链表，每一个节点包含两个值，现在我要把中间一个节点（2,3）替换成（4,5），不使用同步的话，我可以这样实现：
构建一个新的节点连到节点（4,6）上，再将原有（1,1）到（2,3）的指针指向替换成（1,1）到（4,5）的指向。
除了这两者，还有很多不用同步来实现原子操作的方法，比如我曾经介绍过的Peterson算法。
以下这个表格显示了JDK 5.0涉及到的常用容器：
其中：
unsafe这一列的容器都是JDK之前版本有的，且非线程安全的；
synchronized这一列的容器都是JDK之前版本有的，且通过synchronized的关键字同步方式来保证线程安全的；
concurrent pkg一列的容器都是并发包新加入的容器，都是线程安全，但是都没有使用同步来实现线程安全。
再说一下对于线程池的支持。在说线程池之前，得明确一下Future的概念。Future也是JDK 5.0新增的类，是一个用来整合同步和异步的结果对象。一个异步任务的执行通过Future对象立即返回，如果你期望以同步方式获取结果，只需要调用它的 get方法，直到结果取得才会返回给你，否则线程会一直hang在那里。Future可以看做是JDK为了它的线程模型做的一个部分修复，因为程序员以往在考虑多线程的时候，并不能够以面向对象的思路去完成它，而不得不考虑很多面向线程的行为，但是Future和后面要讲到的Barrier等类，可以让这些特定情况下，程序员可以从繁重的线程思维中解脱出来。把线程控制的部分和业务逻辑的部分解耦开。
import java.util.concurrent.Callable; import java.util.concurrent.ExecutionException; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.Future; public class FutureUsage { public static void main(String[] args) { ExecutorService executor = Executors.newSingleThreadExecutor(); Callable<Object> task = new Callable<Object>() { public Object call() throws Exception { Thread.sleep(4000); Object result = "finished"; return result; } }; Future<Object> future = executor.submit(task); System.out.println("task submitted"); try { System.out.println(future.get()); } catch (InterruptedException e) { } catch (ExecutionException e) { } // Thread won't be destroyed. } }上面的代码是一个最简单的线程池使用的例子，线程池接受提交上来的任务，分配给池中的线程去执行。对于任务压力的情况，JDK中一个功能完备的线程池具备这样的优先级处理策略：
请求到来首先交给coreSize内的常驻线程执行
如果coreSize的线程全忙，任务被放到队列里面
如果队列放满了，会新增线程，直到达到maxSize
如果还是处理不过来，会把一个异常扔到RejectedExecutionHandler中去，用户可以自己设定这种情况下的最终处理策略
对于大于coreSize而小于maxSize的那些线程，空闲了keepAliveTime后，会被销毁。观察上面说的优先级顺序可以看到，假如说给ExecutorService一个无限长的队列，比如LinkedBlockingQueue，那么maxSize>coreSize就是没有意义的。
JDK 6.0
JDK 6.0对锁做了一些优化，比如锁自旋、锁消除、锁合并、轻量级锁、所偏向等。在这里不一一介绍，但是给一个例子以有感性认识：
import java.util.Vector; public class LockElimination { public String getStr() { Vector v = new Vector(); v.add(3); v.add(4); return v.toString(); } public static void main(String[] args) { System.out.println(new LockElimination().getStr()); } }在这个例子中，对vector的加锁完全是没有必要的，这样的锁是可以被优化消除的。
CyclicBarrier是JDK 6.0新增的一个用于流程控制的类，这个类可以保证多个任务在并行执行都完成的情况下，再统一执行下一步操作：
上面这个例子就模拟了，两个子任务（分别执行2000毫秒和4000毫秒）完成以后，再执行一个总任务（2000毫秒）并打印完成。
还有一个类似的类是CountDownLatch（使用倒数计数的方式），这样的类出现标志着，JDK对并发的设计已经逐步由微观转向宏观了，开始逐步重视并发程序流程，甚至是框架上的设计，这样的思路我们会在下文的JDK 7.0中继续看到。
import java.util.concurrent.BrokenBarrierException; import java.util.concurrent.CyclicBarrier; public class BarrierUsage extends Thread { private static CyclicBarrier barrier = new CyclicBarrier(2, new Thread() { public void run() { try { Thread.sleep(2000); } catch (InterruptedException e) { } System.out.println("finish"); }; }); private final int sleepMilSecs; public BarrierUsage(int sleepMilSecs) { this.sleepMilSecs = sleepMilSecs; } @Override public void run() { try { Thread.sleep(sleepMilSecs); System.out.println(sleepMilSecs + " secs slept"); barrier.await(); } catch (InterruptedException e) { } catch (BrokenBarrierException e) { } } public static void main(String[] args) { new BarrierUsage(2000).start(); new BarrierUsage(4000).start(); } }JDK 7.0
2011年的JDK 7.0进一步完善了并发流程控制的功能，比如fork-join框架：
把任务分解成不同子任务完成；比如Phaser这个类，整合了CyclicBarrier和CountDownLatch两个类的功能，但是提供了动态修改依赖目标的能力；还有NIO2的新开放特性。这里不详细介绍了。
Java的未来
在多线程编程方面，Java的未来会怎样？
JDK 8.0按计划将在2013年夏天发布，Java从动态语言那里学了很多过来，比如闭包等等，在多线程方面会怎样呢？郁于JLS所限，无法有大的突破，还是有另辟蹊径的办法？纵观整个Java发展的历程，都在努力修正多线程模型实现上的种种弊端，尽可能在保留虚拟机优化特性的基础上给使用者屏蔽细节。
在来回想一下Java最基础的线程模型，其他语言是怎样实现的呢？
比如C#，任何类的任何方法，都可以成为线程的执行方法：
using System; using System.Threading; public class AnyClass { public void DoSth() { Console.WriteLine("working"); } } class ThreadTest{ public static void Main() { AnyClass anyClass = new AnyClass(); ThreadStart threadDelegate = new ThreadStart(anyClass.DoSth); Thread myThread = new Thread(threadDelegate); myThread.Start(); } }上面的AnyClass的DoSth方法，就模拟线程执行打印了一句话。
再来看一门小众语言Io，在语法糖的帮助下，实现更加简单：
thread := Object clone thread start := method("working" println) thread @@start因为Io是基于原型的语言（如果你有兴趣的话，可以在我的blog里找到Io介绍），通过这样的@符号，就实现了新启一个线程运行的功能。
再来看看JDK 5.0的ReentrantLock类，它完全实现了synchronized语义上的全部功能，并且还能具备诸如条件锁、锁超时、公平锁等等更优越的特性（特别值得一提的是tryLock的功能也实现了，就是说可以判定假如这个时间获取锁是否能够成功），甚至在并发量居高不下时，性能还更加优越……我不禁要问，用一个Java实现的锁类去从功能上代替一个已有的同步关键字，这岂不是Java自己在抽自己嘴巴？
import java.util.concurrent.locks.ReentrantLock; public class ReentrantLockUsage implements Runnable { private static ReentrantLock lock = new ReentrantLock(); @Override public void run() { lock.lock(); try { System.out.println("do something 1"); Thread.sleep(2000); } catch (InterruptedException e) { } finally { lock.unlock(); // Why put it in finally block? } System.out.println("finish 1"); } public static void main(String[] args) { new Thread(new ReentrantLockUsage()).start(); lock.lock(); try { System.out.println("do something 2"); Thread.sleep(2000); } catch (InterruptedException e) { } finally { lock.unlock(); } System.out.println("finish 2"); } }其实这个问题渊源已久，JLS在最初把Java锁机制（包括synchronized关键字）定得太死，以至于无法在上面做进一步的修正和优化，无奈只好另外重新建一个类来做这些未竟的事情。如果让Jame Gosling重新回到二十多年前，他也许会选择不同的实现。
关于协程（coroutine）。很多语言都内置了对协程的实现（协程的含义请自行查阅维基百科），听起来似乎是一个崭新的名字，但是其实这个概念一点都不新，JavaScript引擎对单个页面的解析就是通过协程的方式在一个线程内完成的。协程的实现困难有两点，一个是异常的处理，一个是出入线程时现场（包括堆栈）的保存和设置。有一些开源库已经有了Java上协程的实现，如果你感兴趣的话，不妨关注Kilim和Coroutine for Java。
最后，让我们来回顾一下Java多线程发展的历史。从Java诞生到如今有二十年了，可未来会怎样，又谁知道呢？
一、我觉得非原子性的++操作这句话有点模糊，如下所示：
nonAtomicCounter++; 不是原子的原因是因为它是静态/实例变量，需要 读/操作/写对象成员变量。可以加把锁保证读/操作/写原子性
synchronized(atomicCounter) {
nonAtomicCounter++;
}
如果nonAtomicCounter++; 是局部变量 仅有一条指令 iinc i,1；但局部变量又不会线程不安全；
nonAtomicCounter如果是long（64位）的在32位机器即使是局部变量也是线程不安全的（四火补充：在64位机器上也不是线程安全的）；
Atomic×××等类通过Unsafe的compareAndSwap××× 即CAS完成的。
应该是使用成员变量的++时。
二、对于文中这段话：
但是，上面的情况是对boolValue使用volatile修饰保证其可见性的情况下出现的，如果不对boolValue使用 volatile修饰，运行时就一次不会出现（起码在我的电脑上）打印“WTF!”的情形，换句话说，这反而是不太正常的，我无法猜测JVM做了什么操作，基本上唯一可以确定的是，没有用volatile修饰的时候，boolValue在获取的时候，并不能总取到最真实的值。
这个应该是工作内存 和 主内存 同步的问题。 用volatile修饰的变量，线程在每次使用变量的时候，都会读取变量修改后的最的值。
但[boolValue == !boolValue] 和 check/swap 操作并不是原子操作。
也可以通过 在check/swap的两个boolValue加锁来保证同步
synchronized(this) { boolValue = !boolValue; }三、对于DCL问题那段代码，网上也有文章说即使使用volatile也不能保证DCL的安全性：
四、说明：
你给的ibm那个文章链接也说到，“The memory model allows what is known as "out-of-order writes" and is a prime reason why this idiom fails.” 所以根因在于out of order writes，引起的问题是“partially initialized”，但是文章里面提到使用volatile不能解决问题的原因在于一些JVM的实现并不能保证顺序一致性，换句话说，对于 happens-before守则并没有严格遵守，且不说他的说法是否有根据，我谈论这个问题的时候一定是在JLS明确规定以下进行的。至于虚拟机实现上的问题，我不得而知。
另外对于element前面如果不加volatile/final的话，也不能保证解决DCL问题，这里四火做一个说明：
在于instance的可见性由volatile保证了，可是element的name并没有任何语义上的保证，这里可以使用 volatile，但是对于不可变对象其实也可以使用在这里语义弱一些的final，也是可以解决问题的，JSR133对这两个关键字的语义做了强化，我上面给的链接里面也提到了，“the values assigned to the final fields in the constructor will be visible to all other threads without synchronization”。
到此，相信大家对“Java多线程发展史是怎样的”有了更深的了解，不妨来实际操作一番吧！这里是编程网网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
