修复多个线程访问同一个可变的状态变量没有使用合适的同步，所产生的问题：
不在线程之间共享该状态变量
将状态变量修改为不可变的变量
在访问状态变量时使用同步
线程安全性
当多个线程访问某个类时，不管运行时环境采用何种调度方式或者这些线程将如何交替进行，并且在主调代码中不需要任何额外的同步或协同，这个类都能表现出正确的行为，那么就称这个类是线程安全的。
原子性
原子性是指一个操作是不可中断的，要么全部执行成功要么全部执行失败，有着“同生共死”的感觉。及时在多个线程一起执行的时候，一个操作一旦开始，就不会被其他线程所干扰。我们先来看看哪些是原子操作，哪些不是原子操作，有一个直观的印象：
int a = 10; //1 a++; //2 int b=a; //3 a = a+1; //4
上面这四个语句中只有第1个语句是原子操作，将10赋值给线程工作内存的变量a,而语句2（a++），实际上包含了三个操作：1. 读取变量a的值；2：对a进行加一的操作；3.将计算后的值再赋值给变量a，而这三个操作无法构成原子操作。对语句3,4的分析同理可得这两条语句不具备原子性。当然，java内存模型中定义了8中操作都是原子的，不可再分的。
- lock(锁定)：作用于主内存中的变量，它把一个变量标识为一个线程独占的状态；
- unlock(解锁):作用于主内存中的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定
- read（读取）：作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便后面的load动作使用；
- load（载入）：作用于工作内存中的变量，它把read操作从主内存中得到的变量值放入工作内存中的变量副本
- use（使用）：作用于工作内存中的变量，它把工作内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量的值的字节码指令时将会执行这个操作；
- assign（赋值）：作用于工作内存中的变量，它把一个从执行引擎接收到的值赋给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作；
- store（存储）：作用于工作内存的变量，它把工作内存中一个变量的值传送给主内存中以便随后的write操作使用；
- write（操作）：作用于主内存的变量，它把store操作从工作内存中得到的变量的值放入主内存的变量中。
上面的这些指令操作是相当底层的，可以作为扩展知识面掌握下。那么如何理解这些指令了?比如，把一个变量从主内存中复制到工作内存中就需要执行read,load操作，将工作内存同步到主内存中就需要执行store,write操作。注意的是：java内存模型只是要求上述两个操作是顺序执行的并不是连续执行的。也就是说read和load之间可以插入其他指令，store和writer可以插入其他指令。比如对主内存中的a,b进行访问就可以出现这样的操作顺序：read a,read b, load b,load a。
由原子性变量操作read,load,use,assign,store,write，可以大致认为基本数据类型的访问读写具备原子性（例外就是long和double的非原子性协定）
synchronized
上面一共有八条原子操作，其中六条可以满足基本数据类型的访问读写具备原子性，还剩下lock和unlock两条原子操作。如果我们需要更大范围的原子性操作就可以使用lock和unlock原子操作。尽管jvm没有把lock和unlock开放给我们使用，但jvm以更高层次的指令monitorenter和monitorexit指令开放给我们使用，反应到java代码中就是---synchronized关键字，也就是说synchronized满足原子性。
volatile
我们先来看这样一个例子：
public class VolatileExample {
private static volatile int counter = 0;
public static void main(String[] args) {
for (int i = 0; i < 10; i++) {
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
for (int i = 0; i < 10000; I++)
counter++;
}
});
thread.start();
}
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(counter);
}
}
开启10个线程，每个线程都自加10000次，如果不出现线程安全的问题最终的结果应该就是：10*10000 = 100000;可是运行多次都是小于100000的结果，问题在于 volatile并不能保证原子性，在前面说过counter++这并不是一个原子操作，包含了三个步骤：1.读取变量counter的值；2.对counter加一；3.将新值赋值给变量counter。如果线程A读取counter到工作内存后，其他线程对这个值已经做了自增操作后，那么线程A的这个值自然而然就是一个过期的值，因此，总结果必然会是小于100000的。
如果让volatile保证原子性，必须符合以下两条规则：
- 运算结果并不依赖于变量的当前值，或者能够确保只有一个线程修改变量的值；
- 变量不需要与其他的状态变量共同参与不变约束 .
竞态条件
竞态条件（Race Condition）：计算的正确性取决于多个线程的交替执行时序时，就会发生竞态条件。
最常见的竞态条件为：
一，先检测后执行。执行依赖于检测的结果，而检测结果依赖于多个线程的执行时序，而多个线程的执行时序通常情况下是不固定不可判断的，从而导致执行结果出现各种问题。
竞态条件（Race Condition）：计算的正确性取决于多个线程的交替执行时序时，就会发生竞态条件。
最常见的竞态条件为：
一，先检测后执行。执行依赖于检测的结果，而检测结果依赖于多个线程的执行时序，而多个线程的执行时序通常情况下是不固定不可判断的，从而导致执行结果出现各种问题。
对于main线程，如果文件a不存在，则创建文件a，但是在判断文件a不存在之后，Task线程创建了文件a，这时候先前的判断结果已经失效，（main线程的执行依赖了一个错误的判断结果）此时文件a已经存在了，但是main线程还是会继续创建文件a，导致Task线程创建的文件a被覆盖、文件中的内容丢失等等问题。
多线程环境中对同一个文件的操作要加锁。
二，延迟初始化（最典型即为单例）
public class ObjFactory {
private Obj instance;
public Obj getInstance(){
if(instance == null){
instance = new Obj();
}
return instance;
}
}
线程a和线程b同时执行getInstance()，线程a看到instance为空，创建了一个新的Obj对象，此时线程b也需要判断instance是否为空，此时的instance是否为空取决于不可预测的时序：包括线程a创建Obj对象需要多长时间以及线程的调度方式，如果b检测时，instance为空，那么b也会创建一个instance对象
复合操作
实际情况中，应尽可能使用现有的线程安全对象来管理类的状态。与非线程安全的对象相比，判断安全对象的可能状态及其状态换情况要更为容易，从而也更容易维护和验证线程安全性。
(例如AcomicLong） java.util.concurrent.atomic
一个类中很多安全的状态变量，并不一定线程安全。
要保持状态的一致性，就需要在单个原子操作中更新所有相关的状态变量。
内置锁
同步代码块：
一个作为锁的对象引
一个作为由这个锁保护的代码块
以关键字synchronized来修饰的方法就是一种横跨整个方法体的同步代码块，其中该同步代码块的锁就是方法调用所在的对象。静态的synchronized方法以Class对象作为锁。
synchronized (lock){
//访问或修改由锁保护的共享状态
}
每个java对象都可以用作一个实现同步的锁，这些锁被称为内置锁或监视器锁。线程在进入同步代码块之前会自动获得锁，并且在退出同步代码块时自动释放锁，而无论通过正常的控制途径退出，还是通过从代码块中抛出异常退出，获得内置锁唯一的途径就是进入这个锁保护的同步代码块或同步方法。
java的内置锁相当于一种互斥体（互斥锁），这意味着最多只有一个线程能持有这种锁，当线程A尝试获取一个线程b持有的锁时，线程A必须等待或者阻塞，知道线程b释放这个锁。如果b永远不释放锁，那么A也将永远的等待下去。
由于每次只能有一个线程执行内置锁所保护的代码，因此，由这个锁保护的同步代码块会以原子方式执行，多个线程在执行该代码块时也不会相互干扰。并发环境中的原子性与事物应用程序中原子性有着相同的含义- 一组语句作为一个不可分割的单元被执行，任何一个执行同步代码块的线程，都不可能看到有其他线程正在执行由同一个锁保护的同步代码块。