1. 定义
一个类是线程安全的，是指在被多个线程访问时，类可以持续进行正确的行为。
2. WHY
我们想要的是线程安全的程序，为什么在线程安全的开始讲线程安全的类呢？
编写线程安全的代码，本质上就是管理对状态的访问，而且通常是共享的、可变的状态。
我们讨论的的线程安全性，看起来好像是关于代码的，但是我们真正要做的，是在不可控制的并发访问中保护数据。
当多个线程访问一个类时，如果不用考虑这些线程在运行时环境下的调度和交替执行，并且不需要额外的同步及在调用方不必作其它的协调，这个类的行为仍然是正确的，那么称这个类是线程安全的。
对与线程安全类的实例进行顺序或并发的一系列操作，都不会导致实例处于无效状态。
3. 无状态对象是线程安全的
无状态对象：它不包含域也没有引用其他类的域。
例如：
public class MathAdd {
public int add(int a, int b){
return a + b;
}
}
对于MathAdd的实例来说，它只有一个计算两个int数值的的和的add()方法，每个执行线程在运行时，本地变量存储在线程栈中，只有执行线程能够访问，那么无论这个示例被多少个线程并发执行，不同的线程之间并不会相互影响，原因就是：两个线程不共享状态，它们如同在访问不同的实例。
4. 原子性
仍然使用MathAdd来说，假设我们现在需要统计一下，一个MathAdd类的实例被使用的次数，修改后的类如下：
public class MathAdd {
private long count = 0;
public long getCount(){
return count;
}
public int add(int a, int b){
++count;
return a + b;
}
}
此时，MathAdd的实例不再是无状态的对象了，因为其中增加了一个count属性，而多个线程之间又要在add()方法中对count属性进行操作，因此count属性被多个线程共享并操作。
那么这个对象是线程安全吗？不是，因为在add()方法中，有 ++count; 语句，正是这个语句导致对象不是线程安全的。++count; 的执行过程是：先获取当前count的值，然后对当前值加1，将新值写回count，也就是有三个操作，不是一个原子操作。
我自己给原子操作下了一个定义：一个操作是不可分割的，就是原子操作。
5. 竞争条件
当计算的正确性依赖于运行时相关的时序或者多线程的交替时，就会产生竞争条件。也就是说，计算的正确性依赖于时序，会产生竞争条件。
通过代码来进一步理解：
public class LazyInitRace {
private ExpensiveObject instance = null;
public ExpensiveObject getInstance() {
if(null == instance){
instance = new ExpensiveObject();
}
return instance;
}
}
上面的代码是常用的方法惰性初始化，由于某个对象的初始化代价比较昂贵（占用时间和资源），因此延迟对象的初始化，直到程序真正使用它，同时确保它只初始化一次。
上述代码存在竞争条件：当两个线程操作同一个LazyInitRace对象时，A线程检查instace为空，于是new一个对象；这时，B线程也检查instance是否为null，如果A已经成功new了一个对象，那么B线程就直接返回A线程new的对象；但是，也存在这种情况，A正在new对象，但是没有完成，此时instance还是null，于是B线程也来new对象了，这时就存在两个instance对象了，可能直接导致后面所有的程序都是在两个不同的instance对象上操作，导致程序出错。
6. 复合操作
在MathAdd类和LazyInitRace类中，都是由于某个语句或某个语句块不是原子操作：++count;不是一个原子操作；if(null == instance) { instance = new ExpensiveObject(); }更是明显的非原子操作，也就是复合操作，但是我们在运行程序时，只有满足是原子操作操作时，才能保证运行结果的正确性。
正是由于多线程程序会用到复合操作的中间结果，导致了对象不是线程安全。对于多线程共用的对象来说，中间结果可能是正确的，也可能是不正确，任何一个线程都不能依赖于复合操作的中间结果。
俗语说“苍蝇不叮无缝的蛋”，对于多线程来说，Bug专叮依赖于复合操作中间结果的多线程，也可以说Bug专叮依赖于时序的多线程。
7. 内部锁
通过前面的学习，我们发现导致多线程出错的原因，就是对象的某些操作不是原子操作，出现了中间结果，进而导致运行结果错误。因此，Java提供了强制原子性的内置锁机制：syschronized块，语法如下：
synchronized(loack) {
//访问或修改被锁保护的共享状态
}
从synchronized的语法上可以看出，它有两部分：锁对象的引用，以及这个锁保护的代码块。
执行线程进入synchronized块前，需要获得锁，否则必须等待或阻塞；无论通过正常控制路径退出，还是从块中抛出异常，线程都会释放锁。以此，保证了原子性。实例代码：
public class LazyInitRace {
private ExpensiveObject instance = null;
public synchronized ExpensiveObject getInstance() {
if(null == instance){
instance = new ExpensiveObject();
}
return instance;
}
}
注意一点，如果用synchronized修饰方法，那么锁的对象会有不同：
(1) 当方法不是静态方法时，锁是该方法所在的对象本身；
(2) 当方法是静态方法时，锁是该方法所在的class的class对象。
每个Java对象都可以隐式地扮演一个用于同步的锁的角色，这些内置的锁被称为内部锁。
8. 可重入性
当一个线程获得了锁之后，当该线程再次请求获得该锁时，是可以再次成功获得该锁，就是可重入。从逻辑上来说，这是合理的，如果不满足可重入，会出现什么情况呢：
public class Parent {
public synchronized void doSomething(){
System.out.println("doSomething in Parent");
}
}
public class Child extends Parent {
public synchronized void doSomething(){
System.out.println("doSomething in Child");
super.doSomething();
}
}
如果锁不满足可重入性，那么当在Child中调用doSomething时，执行到了super.doSomething()时，永远无法进入，造成死锁。
9. 用锁来保护状态
通过对对象内部的可变状态变量加锁，可以保证对状态变量的操作是原子的，也就保护了状态。
只要保证多线程访问时，每次都用同一个锁来保护变量，就能避免竞争条件。因此，这个锁是否与对象有关都没有关系。但是，为了便利，每个对象都有一个内部锁，所以不需要显式创建锁对象。
对于每一个设计多个变量的不变约束，需要同一个锁来保护其所有的变量。
10. 性能
synchronized块是好的，可以保证操作是原子的。但是，如果将整个方法都加上synchronized的话，那么这个方式就是串行的了，失去了多线程的好处。因此，synchronized块的大小要根据需要设置，甚至可以将不要保证原子操作的两部分代码分别加上synchronized，从而保证多线程的性能。示例代码：
public class Test {
public void doSomething(){
//代码1，不需要保证同步
synchronized(this){
//代码2，保证同步
}
//代码3，不需要保证同步
synchronized(this){
//代码4，需要保证同步，但是跟代码2中没有关联
}
}
}