前言：本系列致力于理清并发编程的理论（其一）和使用Java程序实现并发编程（其二）
多线程的优势
- 发挥多处理器的优势
- 建模更加简单
第一点很好理解：处理器的调度单位是线程，如果程序只有一个线程，最多只能同时在一台处理器上运行，不能发挥多处理器的效率。
第二点，简单点说，就是分工协作。例如一个程序有几个不同的任务可以并发执行，那么在实现过程中，就可以根据任务的不同，在不同的线程中来完成不同的任务。例如：JVM中的垃圾收集器。
其实多线程的优势有很多，知识相对理论化，我们在最开始提到这些知识点，理由很简单：『如果要做一件事，总得知道为什么要做吧！』
多线程带来的风险
- 安全性问题
- 活跃性问题
- 性能问题
线程安全性
概念上来说：如果多个线程访问一个类，不管处理器采用何种调度顺序执行，这个类都能表现出正确的行为——那么这个类就是『线程安全』的。
简言之：一个类的行为和其规范完全一致。
//计数器程序
public int count(){
return value++;
}
value++实际包含三个操作步骤：
read value（假设为1） --> 1+1=2 --> write 2 to value
所以很容易发生这种情况：
| Time | T1 | T2 | T3 | T4 |
|---|---|---|---|---|
| 线程A | read value 9 | 9+1=10 | write value with 10 | |
| 线程B | read value 9 | 9+1=10 | write value with 10 |
虽然有两个线程调用了计数器程序，但是因为处理器的交替执行，导致最终的结果与期望结果不符合，所以这个方法『不是线程安全』的。
活跃性问题
例如：死锁、饥饿、活锁。
性能问题
多线程程序中，线程调度器临时挂起活跃线程，转而执行执行另外一个线程时，需要执行『上下文切换』操作，这些操作也会占用系统资源。所以，只有在设计良好的并发应用程序中，多线程才能提高程序的效率。
共享状态和原子操作
共享状态很好理解，例如前面的例子中的count方法。如果线程A和线程B同时都调用了同一个对象object的count方法，那么，这两个线程都可以同时访问对象object的value域，对象就处于共享状态。
原子操作。前面提到的count++我们已经提到了，实际处理过程中包含三个步骤，所以并不是原子操作。
综合以上两点：一个对象处在共享状态中，并且对于对象的共享状态变量修改操作不是原子操作，这样一个对象，肯定不是线程安全的。那么想要保证对象的线程安全性，只能确保对于对象的修改操作是原子性的。
原子变量类 & 加锁机制
原子变量类估计很少有人听说，因为这种方法很少使用，这里简单介绍：例如，可以使用AtomicLong代替Long或者int类型的count，用于计数。
//声明为final可确保不被在程序无意修改
private final AtomicLong count = new AtomicLong(0);
count.incrementAndGet();//原子操作
加锁机制就是指我们常用的Java内置锁：同步代码块（Synchronized block）机制。一个同步代码块可以看成一个原子操作。
Java中的同步代码块实际包括两个部分：一是作为『锁』的对象引用，也就是共享的可变变量；二是作为由这个锁保护的同步代码块。
Synchronized(object) { //object作为锁的对象引用
//同步代码块
}
我们经常能看到以关键字Synchronized来修饰的方法，其实际上就是一个横跨整个方法体的同步代码块。
重入：一个线程可以获得一个已经由它自己持有的锁。Java内置锁为可重入的锁。
未完待续。。。
