我们来看下面这一段代码
public class demo { public static void main(String[] args) throws InterruptedException { Cou count = new Cou(); Thread t1 = new Thread(() -> { for (int i = 0; i < 10000; i++) { count.add(); } }); Thread t2 = new Thread(() -> { for (int i = 0; i < 10000; i++) { count.add(); } }); t1.start(); t2.start(); t1.join(); t2.join(); System.out.println(Cou.count); } } class Cou { static int count = 0; public void add() { count++; } }
我们期望的结果是得到20000，但是实际上这个值是随机的，它一定是小于20000的。这就是线程安全带来的问题。
说到线程安全问题我们就要知道什么是原子性，我们举一个例子：我们把一段代码想象成一个房间，每个线程就是要进入这个房间的人。如果没有任何机制保证，A进入房间之后，还没有出来；B 是不是也可以进入房间，打断 A 在房间里的隐私。这个就是不具备原子性的。那我们应该如何解决这个问题呢？是不是只要给房间加一把锁，A 进去就把门锁上，其他人是不是就进不来了。这样就保证了这段代码的原子性了。有时也把这个现象叫做同步互斥，表示操作是互相排斥的。一条Java指令不一定是原子的，也不一定只是一条指令。比如我们上面代码的count++，其实是由三步操作组成的：①把cpu上的数据读取到寄存器中 ②修改数据 ③把修改的数据存到内存里。不保证原子性会给多线程带来很多问题，如果一共线程正在修改数据，这个时候另一个线程也开始操作相同点数据就会打断第一个线程的工作，这样结果就很有可能是有问题的。
可见性，就是一个线程修改变量能够及时被其他线程看到。
我们来看下面的图
线程的调度是随机的，抢占式执行，这样就可能会导致执行顺序和逻辑出现问题，我们不知道有多少次自增是正确的，所以结果我们并不知道。
产生线程安全问题的原因
①操作系统中，线程调度的顺序是随机的，抢占式执行。
②两个线程针对同一个变量进行修改。
③修改操作不是原子的。
④内存可见性问题。
⑤指令重排序问题。
我们可以通过加锁来解决线程安全问题
谈到锁我们就要了解 synchronized 的特性，synchronized 会起到互斥效果，如果某个线程执行到某个对象的synchronized 中时其他线程也执行到同一个对象那么synchronized 就会阻塞等待。
阻塞等待：针对每一把锁，操作系统内部都维护了一个等待队列。当这个锁被某个线程占有的时候，其他线程尝试进行加锁，就加不上了，就会阻塞等待，一直等到之前的线程解锁之后，由操作系统唤醒一个新的线程，再来获取到这个锁。
进入synchronized 修饰的代码块相当于加锁，退出synchronized 修饰的代码块相当于是解锁。
上一个线程解锁之后, 下一个线程并不是立即就能获取到锁. 而是要靠操作系统来 “唤醒”. 这也就是操作系统线程调度的一部分工作.假设有 A B C 三个线程, 线程 A 先获取到锁, 然后 B 尝试获取锁, 然后 C 再尝试获取锁, 此时 B和 C 都在阻塞队列中排队等待. 但是当 A 释放锁之后, 虽然 B 比 C 先来的, 但是 B 不一定就能获取到锁, 而是和 C 重新竞争, 并不遵守先来后到的规则 .
synchronized(lock){ synchronized(lock){ ...... }//2 }//1
我们假设第一次加锁成功，这个时候lock就属于是被锁定状态，再进行第二次加锁，这个时候应该是阻塞等待状态，要想加锁成功就需要等到锁释放后才能加锁成功。但是实际上一旦第二次加锁阻塞了就会出现死锁。要想第二次加锁成功就需要第一次加锁释放锁，第一次要想释放锁就需要执行到 1 的的位置，而执行到 1 的位置就需要第二次加锁成功，但是由于第二次加锁导致了阻塞，这样就没有办法执行到 1 ，也就无法释放锁。
synchronized 是可重入锁，就是一个线程针对一把锁连续加锁两次，不出现死锁，这种锁就是可重入锁。可以有效的解决上面死锁的问题。
在可重入锁的内部，包含了 “线程持有者” 和 “计数器” 两个信息。如果某个线程加锁的时候，发现锁已经被人占用，但是恰好占用的正是自己，那么仍然可以继续获取到锁，并让计数器自增。解锁的时候计数器递减为 0 的时候，才真正释放锁。(才能被别的线程获取到 )
造成死锁的四个必要条件
1.互斥作用（锁的基本特性）：当一个线程加锁了，另一个线程想要获取这把锁就需要阻塞等待。
2.不可抢占（锁的基本特性）：当锁被一个线程拿到后，另一个线程只能等这个线程释放锁后才能拿到这把锁，不能强行抢占。
3.请求保持（代码结构）：一个线程尝试获取多把锁（拿到一把锁后还没有释放就想着获取另一把锁）。
4.循环等待/环路等待（代码结构）：等待的依赖关系形成了环。
只有同时出现上述四种情况才会出现死锁。我们要想解决死锁，就需要避免上述四种情况同时出现，第一条和第二条是synchronized的特性，我们改变不了，所以只能避免三和四同时出现。对于三来所，避免编写锁嵌套逻辑并不好使，所以我们可以针对四来解决死锁。我们可以约定加锁的顺序，避免循环等待，我们可以针对锁进行编号，比如加多把锁的时候，先加编号小的锁，再加编号大的锁（所有线程都遵守）
我们来看下面的代码
public class Thread1 { private static int isQuit=0; public static void main(String[] args) { Thread t1 = new Thread(()->{ while (isQuit==0){ //循环什么都不做 } System.out.println("t1退出"); }); Thread t2 = new Thread(()->{ System.out.print("请输入isQuit:"); Scanner scanner = new Scanner(System.in); //输入不为0则t1线程结束 isQuit = scanner.nextInt(); }); t1.start(); t2.start(); } }
我们预期结果应该是输入不为0则t1线程结束但是我们输入 1 t1线程并没有结，我们通过jconsole可以看到t1线程的状态是RUNNABLE正在执行。
这也是一个线程安全问题，之前我们是两个线程同时修改一个变量，这次是一个线程读一个线程修改，这种情况也有可能会有问题。这就是由内存可见性引起的。因为我们上面说过，load把isQuit的值读取到寄存器中，让后通过cmp指令判断是否为0，因为这个循环速度很快短时间内会进行大量的load和cmp操作，此时，编译器发现进行了这么多次load操作结果都是一样的并且load操作还很费时间，一次load相当于上万次cmp，所以编译器就做了一个大胆的决定，只在第一次循环的时候读取内存后续都不读取，只从寄存器中读取isQuit，这是编译器的自我优化，编译器的初衷是提升程序效率，但是提高程序效率的前提是逻辑不变，但是此时修改isQuit的操作是另一个线程操作的，编译器不能正确判断，以为isQuit没有修改，所以就引起了bug。而编译器什么时候会优化我们无法推断，所以我们可以用volatile 来告诉编译器不要优化，这样程序就不会出错。
public class Thread1 { private volatile static int isQuit=0; public static void main(String[] args) { Thread t1 = new Thread(()->{ while (isQuit==0){ //循环什么都不做 } System.out.println("t1退出"); }); Thread t2 = new Thread(()->{ System.out.print("请输入isQuit:"); Scanner scanner = new Scanner(System.in); //输入不为0则t1线程结束 isQuit = scanner.nextInt(); }); t1.start(); t2.start(); } }
