根本原因：随机调度，抢占式执行
多个线程同时修改同一个变量
修改操作不是原子的
内存可见性
指令重排序
上面这段代码可以正常打印出hello，按照我们前面所学，第一次加锁之后，第二次加锁应该有所冲突啊。这里是因为是同一个线程加锁。在synchronized中，第一次加锁会记录线程和计数器为一，下次加锁会判断是否为一个线程。如果不是一个线程则阻塞，是一个线程计数器++。
我们把这个特性叫做可重入
死锁
1.一个线程，一把锁。
这就是我们上面的情况。不过我们用可重入锁来进行了解决
2.两个线程，两把锁
这个给也会成为死锁。我们可以调整加锁顺序来解决。
3.n个线程，m把锁
哲学家就餐问题
我们可以引入加锁顺序来解决
内存可见性
这个代码当我们输入非0的时候，按理说应该结束t1线程但实际并没有。这就是内存可见性问题
因为我们在循环中，不断地执行取fag和判断是否等于0的操作，jvm在优化过程中，进行了误判，后面的读取并不是读内存的fag而是寄存器/缓存中的fag。
解决这个问题我们可以用volatile关键字解决，在变量前加上即可
volatile有俩个功能，保证内存可见性，禁止指令重排序。
