根本原因：随机调度，抢占式执行

多个线程同时修改同一个变量

修改操作不是原子的

内存可见性

指令重排序

上面这段代码可以正常打印出hello，按照我们前面所学，第一次加锁之后，第二次加锁应该有所冲突啊。这里是因为是同一个线程加锁。在synchronized中，第一次加锁会记录线程和计数器为一，下次加锁会判断是否为一个线程。如果不是一个线程则阻塞，是一个线程计数器++。

我们把这个特性叫做可重入

死锁

1.一个线程，一把锁。

这就是我们上面的情况。不过我们用可重入锁来进行了解决

2.两个线程，两把锁

这个给也会成为死锁。我们可以调整加锁顺序来解决。

3.n个线程，m把锁

哲学家就餐问题

我们可以引入加锁顺序来解决

内存可见性

这个代码当我们输入非0的时候，按理说应该结束t1线程但实际并没有。这就是内存可见性问题

因为我们在循环中，不断地执行取fag和判断是否等于0的操作，jvm在优化过程中，进行了误判，后面的读取并不是读内存的fag而是寄存器/缓存中的fag。

解决这个问题我们可以用volatile关键字解决，在变量前加上即可

volatile有俩个功能，保证内存可见性，禁止指令重排序。