一.啥是线程安全问题
有些代码，在单个线程执行时完全正确，但同样的代码让多个线程同时执行，就会出现bug。例如以下代码：
给定一个变量count，让线程t1 t2分别自增5000次，然后进行打印，按理说count应变成10000，但实际却小于1000：
这是因为，count每增加一次，cpu都要执行三个指令：1.load：把数据从内存读取到cpu寄存器中；2.add：把寄存器中的数加一；3.save：把寄存器中的数保存到内存中。由于cpu的调度顺序随机，就可能导致有些调度顺序下，上述逻辑出现问题。（注意：每一次调度都是执行一条指令）
首先要明确，不同的线程将内存中的值进行加载时，会加载到不同的cpu寄存器中，不同寄存器是相互独立的。然而内存只有一个，所以一个变量在内存中只能有一个值
t1 t2
load
add
save
load
add
save
上面这是最理想的状态这样下来的俩次count++后，count的值变为2，但可能有如下情况：
t1 t2
load
add
load
save
add
save
首先，内存中的count是0，然后执行第一个load，加载到寄存器1中count=0,然后add，寄存器1中的count=1.然后执行t2的load，也就是把内存中的count加载到寄存器2中，而此时内存中的count还没有更新为1，所以加载时寄存器2中的count=0，而和t1所在的寄存器1中的值不同。所以t1进行保存时，保存到值是count=1,然而t2进行add，就是把寄存器2中的count进行+1操作，然后save，这导致保存时保存到还是1。所以俩次count++操作后，内存中的count=1而不是=2！！！
还有很多种情况
那有没有可能最终count<5000呢？有可能。因为可能在t1的一次load和save之间t2连续执行多次，也就是首先t1将内存中的count=0加载到自己的寄存器1中，然后下一步就是t2连续进行了5次count++，这时寄存器2中的count=5并保存到了内存中，然后下一步就是t1把自己寄存器中的count=0加了1，然后把count=1保存到了内存中。可有人又说，这样执行下去，反正t1要执行5000次，那么count不就是5000吗？可我想说，既然t2可以多次执行，那也就有可能接下来又几次是t1多次执行，这样就有可能小于5000。
二.线程安全产生的原因
1.操作系统中，线程的调度是随机的
2.俩个线程，针对同一个变量进行修改
3.修改操作不是原子的
count++是分三步进行的，也就是有三个指令
4.内存可见性问题
5.指令重排序问题
4和5会在以后的文章中讲解到
三.如何解决线程安全问题
1.针对原因1，无法解决，因为这是系统内核实现的，无法按修改
2.针对原因2，可通过调整代码结构，修改代码逻辑来解决，但很难实现
3.原因3，可以让操作变成是原子的，这就用到了之前提到过的加锁问题。如何加锁？使用synchronized关键字
四.synchronized关键字
1.synchronized工作原理
synchronized是针对对象进行加锁的，在摸个线程已经对一个对象进行加锁并运行时，如果有另一个线程尝试对该对象加锁，就会产生锁竞争，后一个线程就会阻塞等待，直到前一个线程解锁为止。
2.加锁举例
对代码块进行加锁：
注意，进行加锁的对象没有要求，可以任意。如上，让t1和t2都针对同一个对象进行加锁，t2就会等t1执行完后再和执行，打印出来的就是10000.
这是因为，t2由于锁竞争，导致lock操作出现阻塞，直到t1unlock之后，t2的lock操作才算结束
在t2的等待过程中，t2就表现出了BLOCKED状态
加锁形成了串行执行的效果，使得线程安全问题迎刃而解
synchronized除了对代码块加锁以外，还可以修饰实例方法或静态方法
注意对方法进行加锁，可以直接在方法前面加上关键字。那就有疑问了，不需要指定对象进行加锁吗？在这里，当在方法前加关键字时，默认的加锁对象就是this，所以上述代码就等价于：
而对于静态方法，也是有以上两种做法，只不过，第二种方法不能简单地使用this（因为静态方法之中没有this）而应如下使用:
注意这里的count应该是静态属性。Counter.class就是通过反射的方式来获得类对象。反射学习请仔细阅读http://t.csdnimg.cn/2WmtY
这里再强调一下：反射的本质就是依靠类对象作为支撑。
类对象如何产生？首先是.java程序被编译生成.class文件，然后.class文件被jvm加载到内存中产生一个数据结构，此数据结构就是类对象。
类对象中包含：1.类的属性有哪些，都是啥名字啥类型啥访问权限；2.类的方法有哪些，都是啥名字啥类型啥访问权限；3.类本身继承自哪个类，实现了哪些接口。
同时，类对象在一个java进程中时唯一的，如：写了一个counter类，那么在内存中只有一个counter类对象。
3.synchronized一些特性
1.互斥性
就是说，一个对象被上了锁，另一个对象就得等待释放。那么如何知道该对象已经被上锁？这就用到了对象头
synchronized用到的锁是存在于对象头中的
什么是对象头？Java的一个对象，对应的内存空间中，不仅有我们自己定义的属性，还有一些自带属性（储存在对象头中）。在对像头中就有一些属性是表示当前对象是否加锁。（对象头中存储了对象是很多java内部的信息,如hash码,对象所属的年代，对象锁，锁状态标志，偏向锁（线程）ID，偏向时间等）
2.可重入性
所谓可重入锁，就是指：一个线程连续对同一把锁加锁来此，不会出现死锁问题。满足此要求就是可重入，反之就是不可重入。要想详细了解可重入，就要先了解死锁。
五.死锁
1.死锁的表现形式
一个线程，针对同一把锁连续加锁俩次
如果不是可重入锁，就会出现死锁问题，如下：
synchronized(locker){
synchronized(locker){
}(1)
}(2)
如上是一个线程，假设synchronized是不可重入锁。第一次成功加锁了，到了第二次，要想加锁，就得第一次的所执行结束并释放锁；但第一次的锁要想结束，就得第二次的锁加锁成功。这就是形成矛盾，也就是死锁了。
但synchronized是可重入的，这使得locker锁可以记录下是哪个线程在对它进行加锁，后续再加锁时，若枷锁线程是当前持有锁的线程，就可以加锁成功。
那么此时就有一个问题：上述例子中，执行到{(1)时，是否应该释放锁？不可以释放！！！否则后面的代码就没有锁的保护了，就会出现线程安全问题。不管锁了几次，都应该在最后全部执行完再释放锁。
那么如何知道代码已经执行完了呢？这就引入了引用计数：在锁对象中，不仅要记录随拿到了锁，还要记录锁加了几次。每加一次锁，计数器就加一，每解一次锁，计数器就减一，直到最后，计数器为0。
俩个线程俩把锁
首先t1获取到了A锁，t2获取到了B锁
然后t1想获取B锁，t2想获取A锁。但是A锁已被t1持有，B已被t2持有并且都没释放，所以俩线程就会阻塞等待，死等待，都完成不了，也都释放不了
代码如下：
每个线程加了一把锁之后休眠1秒，就是为了保证俩个线程都至少获取到了一把锁，二避免出现有一个线程没获取到锁二另一个线程把俩把锁都获取到的情况
我们会发现，什么都没有打印，因为线程1获取不到锁2，线程1就完成不了，同理，线程2也完成不了，这就形成了死锁
n个线程m把锁，更易出现死锁问题
典型模型：哲学家就餐问题。
每个哲学家有俩件事可做：一个是思考问题不吃面条，另一个是吃面条不思考（吃面时会拿起做有俩根筷子。规则如下：哲学家啥时候思考啥时候吃是随机的；吃一次面条吃多久是随机的；当一个哲学家正在吃面条时，另一个哲学家突然想吃面条，那么这另一个哲学家就会阻塞等待（而不会先去思考，直到那个哲学家放下筷子。
一般情况下可正常进行，但有极端情况：五个哲学家同一时刻同时想吃面条，于是同时拿起了左手的筷子，二当他们同时去拿右手筷子时，都没有筷子了，所有人都会阻塞等待右手边的筷子，这就出现了死等待问题，也就是死锁。
2.死锁的成因
我们只讲4个必要条件，这四个条件都满足才能出现死锁问题
互斥使用（这是锁的基本特性）
当一个线程持有一把锁后，另一个线程要想获取到这把锁，就必须要阻塞等待
不可抢占（这也是锁定基本特性）
当锁被线程1拿到后，线程2只能等待线程1将锁释放后才能拿到，而不能与1抢夺
请求保持
一个线程尝试获取多把锁：线程拿到锁1后，又想同时拿到锁2，并且在拿的时候不想释放锁1，也就是请求保持锁1在它手里。这就和上面俩个线程俩把锁的情况类似：
循环/环路等待
就是说，等待的依赖关系形成了环，也就是典型的哲学家就餐问题。
3.如何避免/解决死锁问题？
只要上述四个必要条件中有一个没成立，就可以解决死锁问题。但前俩个是锁的特性，无法改变，所以只能从三四入手
针对请求保持问题进行解决
只要规定用完一个锁之后才能使用另一个锁，就可以解决这个问题，代码如下：
针对循环/环路等待问题进行解决
上述规定用完一个锁之后才能使用另一个锁，这样的规定不一定能够满足用户需求，有些就是得嵌套使用，那该如何解决？
给锁进行编号，规定从小到大或从大到小进行锁的取用。（比如从小到大取，线程1用了1号锁，此时线程2想加锁，他也只能取用1号锁，所以就得等待线程1将1锁释放；而线程1在释放锁1之前要是还想加锁，就可以继续加2号锁（剩余锁中的最小号）......）
还是上面的例子，就可以如下解决：
这里虽然还是嵌套的锁，但由于都是先加锁1再加锁2，所以没有出现死锁问题