synchronized 关键字
Lock 接口
ReentrantLock 类
1. 线程同步问题的引入
测试代码如下：
运行结果：本来是100张票，但是结果是101次
分析：这是由于程序中当线程名字是Thread-0时，线程休眠10ms，这时线程是阻塞的，且并没有将ticket减1；这时其他线程正常运行，就会导致线程同步问题
2. java的线程同步关键字synchronized
2.1. 同步方式一
synchronized(非匿名的任意对象){
线程要操作的共享数据
}
修改RunnableThread类，加入线程同步：
加上同步之后，线程就没有同步异常的问题了
synchronized(obj)中的obj相当于是一个同步锁，没有get到锁的线程不能进入同步，在同步中的线程如果没有运行到synchronized的最后，则不会释放锁
另外，加上了线程同步之后，程序的运行速度会明显减慢
2.2. 同步方式二：同步方法（推荐方式！）
好处：代码简介，使用清晰，省去synchronized中的 非匿名任意对象，而这个obj对象由本类对象引用this隐式代替，只是没有写出来而已。
方式：将线程共享数据，同步，抽取到一个方法中，在方法的声明处加入同步关键字
void synchronized shareFunction(){
critical section
}
修改2.1：
说明（了解一下）：
当同步方法是非静态方法的时候，obj锁是它自己this，this被系统隐式处理了
但当同步方法是静态static的时候，obj锁是本类.class，在这个例子当中就是RunnableTread.class，class是一个属性。同时，静态的同步方法，必须对应静态的共享变量，这里的ticket必须要用static修饰，因为静态方法中是没有this和supper的
对synchronized的补充：
如果拿到synchronized的线程异常退出了，那么等待锁的线程是否会一直等待呢？
答案是否定的，当JVM发现有锁的线程异常了之后会将它的锁自动释放，再由其它等待的线程拿到锁
引申：
前面我们介绍过StringBuffer和StringBuilder类
StringBuffer类说它是一个线程安全的类，现在我们查看StringBuffer的源码，发现这个类，除了构造方法，其他所有的方法都使用了synchronized关键字修饰
而StringBuilder类是一个线程不安全的类，因为源码中它的方法是没有synchronized修饰的
3. 从JDK1.5开始的Lock接口替代synchronized关键字
synchronized的缺陷：
如果获取锁的线程由于要等待IO或者其它原因（比如sleep）被阻塞了，但是又没有释放锁，其它线程便只能等待，这样非常影响程序执行的效率。因此就需要一种机制：可以不让线程一直无期限等待下去（比如只等待一定时间或者能够相应中断），通过Lock就可以办到。
又假设当多个线程读写文件时，read-write会发生冲突现象，write-write会发生冲突，但是read-read不会发生冲突。如果采用synchronized，就不能让read-read同时进行，只要有一个线程read，其他想read的线程都只能等待，严重影响效率。一次需要一种机制：使得多个线程都只是read时，线程之间不会发生冲突，通过Lock就可以办到。
另外通过Lock可以知道线程有没有成功获取到锁，这个是synchronized无法办到的。
Lock和synchronized的区别：
Lock是一个接口，不是Java语言内置的，synchronized是java语言内置的关键字。
Lock与synchronized有一点非常大的不同，采用synchronized不需要用户区手动释放锁，当synchronized方法或者synchronized代码块执行完之后，系统会自动让线程释放对锁的占用；而Lock则必须要用户区手动释放锁，如果没有主动释放锁，就有可能导致出现死锁。
3.1. Lock接口的方法
void lock()
获取普通锁，如果锁已被获取，则只能等待，功能等同于synchronized关键字。但不同的是Lock后必须unLock锁，一般来说，Lock必须在try{}catch{}中进行，并且将释放锁的操作放在finally块中进行，以保证锁一定被释放，防止死锁的发生。
void lockInterruptibly()
例：当2个线程同时通过lock.lockInterruptibly()想获取某个锁时，假设A线程获取到了锁，那B线程只能等待，那么对B线程调用threadB.interrupt()方法能够终端B线程的等待过程。注意，当A线程获取了锁后，是不会被interrupt()方法中断的；因此通过lockInterruptibly()方法获取锁时，如果没有获取到，只能等待，只有等待状态下的线程才是可以响应中断的！
boolean tryLock()
尝试获取锁，如果获取成功返回true，反之返回false。也就是说，这个方法无论如何都不会阻塞等待获取锁
boolean tryLock(long time, TimeUnit unit)
等待time时间，如果在time时间内获取到锁返回true，如果阻塞等待time时间内没有获取到锁返回false
void unlock()
业务处理完毕，释放锁
3.2. ReentrantLock
3.2.1. lock()-unlock()
使用Lock接口使程序中的应用更为灵活，类似于C++中对锁的使用方式，效果和synchronized关键字是一样的
下面我用Lock接口的实现类ReentrantLock类来改造售票程序
这里需要将unlock加入到finally中，否则当程序异常的时候，锁没有被释放
3.2.2. tryLock()-unLock()
略
3.2.3. lockInterruptibly()-unLock()
略
3.3. ReadWriteLock接口
使用读写锁，可以实现读写分离锁定，读操作可以并发进行，写操作锁定单个线程
如果有一个线程已经占用了读锁，则此时其他线程如果要申请写锁，则申请写锁的线程会一直等待释放读锁
如果有一个线程已经占用了写锁，则此时其他线程如果申请写锁或者读锁，则申请的新城会一直等待释放写锁
已实现的类：ReentrantReadWriteLock
4. 死锁问题
下面这个图是我认为对死锁问题最形象的描述
用代码实现上图死锁的例子：
创建自定义LockA、LockB类，创建DeadLock类重写Runnable的run方法，在主程序中起2个线程。
对LockA、LockB类的说明：
第一次使用private来修饰构造函数，作用是为了防止对象被主程序new对象
使用public static final修饰locka和lockb是为了让程序能够静态调用LockA中的locka和LockB中的lockb，并且locka、lockb不能够被修改
结果来看，前4行是同一个线程正常抢到ab锁或ba锁并释放
但是第5，6行一个线程抢到了b锁，另一个线程抢到了a锁，这样就产生了开始图中的死锁，2个线程都不会再继续运行，都卡在打印处了
5. 线程间通信：线程的等待与唤醒
在多线程运行中，有时候某个线程依赖于其他线程的运行结果，这样就需要被依赖的线程去通知依赖线程，那么就会使用线程的等待和唤醒。
所使用的方法：
wait():等待，将正在执行的线程释放其执行资格 和 执行权，并存储到线程池中
notify():唤醒，唤醒线程池中被wait()的线程，一次唤醒一个，而且是任意的
notifyAll():唤醒全部线程，将线程池中的所有等待线程唤醒
5.1. 未做等待唤醒示例：
有一个输入端，有一个输出端，有一个Person类（类中只有2个成员：姓名和年龄）。要求输入端只负责输入Person类的信息，输出端负责打印Person类的信息
查看打印结果：
5.2. 使用synchronized解决异常问题
修改程序：
Person类和主程序不用修改
InputPerson类和OuputPerson类都在在临界区加上synchronized，并且锁一定要用公共的Person对象
再运行，发现没有异常现象存在了
5.3. 使用等待唤醒来控制输入输出
在5.2中，虽然解决了输出异常的问题，但是若输入或者输出线程在某一段时间持续获得CPU调度，那么实际上这个程序没有太大的意义。
我们希望实现的功能是，当输入线程输入Person数据时，输出线程打印这个输入数据，那么这样我们就可以使用等待唤醒的功能。
输入线程：输入完成后，等待，等待输出打印结束，开始下一次输入
输出线程：输出完成后，等待，等待输入重新复制，开始下一次输出
主程序不变
修改Person类：加一个flag来判断输入线程该输入还是等待，输出线程该输出还是等待
修改InputPerson类和OutputPerson类
输出结果：
Kluter 35和Lesslin 27交替出现
引申：
这里一定要注意wait和notify方法是Object的方法，理论上是可以直接匿名类调用的（也就是直接写wait()和notify()），但是这里一定要用Person类的方法，否则会exception：java.lang.IllegalMonitorStateException
如果不写p.wait()，jvm就不知道你要监视的wait和notify的对象是什么！