目录
3.CountDownLatch—大号的Join方法—计数器
CAS全名：Compare and Swap ： 比较交换
这种实现不会阻塞线程，而是不断尝试更新。
V的值代表读取到的最新主内存值，A代表当前工作内存中写入的值，B则是想要写回主内存的值
1.比较内存中的值V和当前工作内存的值A是否相等
2.若相等，可以认为当前主内存的值没有被修改，就把值B写回主内存
若不相等，说明当前线程的值A已经过时了，不是最新的主内存值，此时需要将主内存的最新值V覆盖到A上，保存最新的工作内存，这时值B就不能写回主内存了，需要重新循环重新修改。
java.util.concurrent.atomic包中的所有类都是线程安全的原子类
i++本身是线程不安全的。
除了上锁之外，我们可以通过atomic包下的原子类来实现
AtomicInteger count = new AtomicInteger();这样我们可以进行 变量 的 ++ 或者 -- 操作：
假如两个线程同时进行i++操作，线程1先执行了：
这是V变成了1，然后线程2执行++操作
我们会发现，线程2的A保存的是0，V！=A ，所以需要重新读取值并进行++操作。
经过重新操作后，线程2将数据写回主内存
如此循环往复，就会实现原子性
自旋锁已经说过了，就是获取锁失败的线程不是进入阻塞态，而是一种循环态，会在CPU上空转，不断查询当前锁的状态。
也就是说只有当this.owner==null时，代表此时没有对象占用锁，就尝试加锁操作。
ABA问题实际上就是当一个线程做了很多事，但是值最终还是没有变化时，把这个值再写会主存，这个时候另一个线程看到的值仍是自己工作内存的值，因此会直接用，但是其实不能直接用的。
假定：两个线程同时获得同一主内存值，并存放到自己的工作内存。
此时 线程1 进行一系列的运算和修改 自己线程中的值在不断变化，但最后又变回了初始值。
将值写回主存，此时主存还是那个值，线程2直接读取了。
当CAS的V==A时，我们先判断版本是否正确，在进行操作。
如果不等，那也不需要判断版本了。
根据竞争的激烈程度，会进行无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁的自动升级。
这里我就直接盗图了。
没有线程开始，没人获取锁
当第一个线程尝试获取锁时，就把偏向锁给线程1，若是线程1再次获取锁时，没有加锁解锁过程，就验证一下锁的持有者是否是t1即可。
当第二个线程尝试获取锁JVM就会取消偏向锁的状态，升级为轻量级锁
使用CAS（自旋锁）来进行轻量级锁的获取。
此状态没有获取锁的线程就一直自旋。
重量级锁依赖操作系统，通过mutex实现，用户态切换到内核态。
此时线程竞争非常激烈，一般这么几种情况会导致轻量级锁升级为重量级锁：
1.多个线程竞争轻量级锁(一般来说是线程数为CPU核数的一半)
2.自旋次数超过10次以上，为了避免CPU空跑，升级为重量级锁。
3.调用了Object.wait()方法，无论竞争是否激烈都升级锁，因为wait方法需要对象monitor实现，和mutex相关
和Runnable最大的区别就是带返回值，并且返回值用FutureTask子类接收
同样的，我们需要Thread接收FutrueTask对象来启动线程。
FutureTask的获取call方法的返回值，调用get方法的线程会一直阻塞直到call方法执行结束，有返回值再继续执行。
来自java.util.concurrent中的Lock接口也可以实现对象锁。
在JDK 1.5之后，Java语言自己实现的互斥锁实现，不需要借助操作系统的monitor机制。
加锁：
1.死等法：
2.等会儿就算：
解锁：
一图流了
信号量Semaphore是一个计数器，表示当前可用资源的个数。
1.申请资源操作：
2.释放资源操作:
我们每次也可以尝试获取和释放多个资源：
CountDownLatch countDownLatch = new CountDownLatch(10);调用await方法需要等待其他线程将计数器减为0，才能继续向下执行。很像join方法。
countDownLatch.await();调用countDown方法使计数器 -1
countDownLatch.countDown();以上几种工具类就是juc包的常用工具类，尤其是：
信号量—Semaphore 计数器—CountDownLatch
举个例子：A线程在运行途中开始等待B线程唤醒自己
同时，B线程也在等待A线程唤醒自己
他俩谁都无法继续进行，也无法相互唤醒，全都卡在那了。
其实很简单，只要避免多个线程获取资源不要成一个循环就可以了。
