多线程·锁池与等待池(jdk1.8)；在乐观锁下，真的有必要关心CAS中的ABA问题吗？？？
目录
本来不想聊关于线程的话题，主要原因在于自己对计算机原理相关的知识了解太浅，怕耽搁大家。
可是网络上的文章太多东拼西凑、莫名其妙，最近在读一些博文的时候被气到了，于是勉强阐述一些个人在线程方面的理解。
进程、线程、协程
当说起线程的时候，总是避不开进程和协程，较官方些的定义如下：
进程：操作系统分配资源的基本单位，有独立的内存空间，通信效率低，切换开销大
线程：CPU调度的基本单位，共享父进程的资源，通信效率高，切换开销小
协程：数据安全，可由程序控制调度
在具体的使用过程中，进程相对于线程来说最主要的特点是安全，安全指的是线程存在于进程中，进程挂掉意味着所有的线程也一起销毁。比如nginx服务器，典型的多进程+多路复用，master进程负责接收请求、管理worker进程；worker进程处理请求，多路复用的目的是为了减少线程创建的开销；还有cache进程等。
协程相对于线程来说特点有两个，安全、效率。两个特点来自于协程的实现，协程使用同步实现异步，同步就意味着没有资源竞争，没有锁开销，没有切换开销；调度策略由开发者自行控制，可以回忆一下关于asm编程时的中断。
而在java中，使用最多的是线程，所以java程序员了解最多的也是线程。
线程的目标
首先必须要清楚使用线程的原因，最简单的，使用线程是为了提高程序性能。而线程解决的是IO密集型问题与CPU利用率问题。
IO密集指的是有大量的操作需要读/写，而此时的CPU处于等待状态，这种情况就是通常所说的BIO模式。
而我们作为一个残忍的剥削者，对于CPU老实的恶劣行径，是万万不能容忍的。这个时候就需要给他下达命令：“你先处理其他的事情吧，等会儿IO完成了再回来搞”，CPU于是把此时的IO操作先放在一边，屁颠屁颠地做其他的事情去了。
但是呢，CPU在处理其他事情的时候脑子里还记着刚才的IO操作，他可不能把这茬给忘了，所以这个做事的效率就差了一些，这个就叫存储上下文信息，即线程切换时的开销。
与之相对的就是计算密集，单CPU多线程不能解决计算密集问题，效果甚至比单线程更差。
比如今天你有两个计划：1.工作2.吃鸡
如果你花10s工作，再花10s吃鸡，如此反复，最终不光工作一塌糊涂，吃鸡估计也是吃不到了。
但是如果这个时候你的好哥们到你家来了，诶，现在相当于有两个CPU了。你认真工作，然后跟你哥们说：“你上我的号，帮我吃鸡吧，晚上请你吃饭”，这下就完美了，谁也不闲着，且都能专心做，这个就叫CPU充分利用。
线程的切换
线程的切换带来的另一个问题是共享资源的控制。
假设现在有一个餐厅，餐厅里有一张餐桌，厨师每做出一盘菜就端到餐桌上，但是呢，餐厅中没有灯，黑漆麻乌的啥也看不见。
在这里餐桌就是共享资源，餐桌上的菜就是资源的值，黑漆麻乌表示在操作资源前不知道资源的状态。
人们到了餐桌前徒手一扒拉，不论能否拿到餐盘，扒拉完一次就得走。如果有的人啥也没拿到，你说他下次还会光临吗？
后来啊，餐厅老板意识到了这个问题，于是在门口贴了一个二维码，每个客人就餐前需要扫码登记，登记完喊到谁的名字就让谁进，于是每出一盘菜老板就根据统计表里的人喊一嗓子，这个被喊到的人就能进入餐厅吃饭了，这个就是线程锁。
你觉得现在已经都搞定了，然而太天真了！
有的客人被翻到了牌子，进入餐厅正准备吃食，万事俱备之际，该客人突然闹肚子，遂狂奔茅厕。难道其他客人都等着他？不可能的，效率太低了！老板在该客人蹲坑的时候把他的名字记到小本本上，等他出来了，把他的名字再次登记一遍，这段时间不影响其他客人就餐，这个就叫线程的挂起与唤醒。
在java中，有两个概念，锁池与等待池(synchronized)：
锁池：某个线程已经拥有了某个对象的锁，其他想要获取该对象的锁的线程就会进入该对象的锁池中
等待池：已经拥有某个对象的锁的线程调用了wait()方法，该线程将进入该对象的等待池中，等待池中的线程不会竞争该对象的锁
当执行该对象的notify()方法时，随机将等待池中的一个线程移到锁池中；当执行该对象的notifyAll()方法时，将等待池中的所有线程移动到锁池中。
锁池中的线程可以竞争该对象的锁。
wait()、notify()、notifyAll()实质上就是线程在锁池与等待池之间的移动，每个锁对象都有自己的锁池和等待池。
线程的管理
即便线程能够通过锁来控制合理的执行，但线程仍然不能够无限地创建，就算你不在乎线程切换的开销，但计算机的内存毕竟是有限的。
餐厅老板不可能让等待就餐的顾客从餐厅门口排队排到法国（麻烦法国的那位哥们帮我带瓶红酒回来，谢谢）。
线程池由此诞生，其最主要的作用我认为就是对于线程数量的控制：
1.降低资源消耗
2.提高响应速度
3.线程可管理性
在java中，常见的线程池有四种：
1. newCachedThreadPool()
2. newFixedThreadPool()
3. newScheduledThreadPool()
4. newSingleThreadExecutor()
四种线程池都是由ThreadPoolExecutor实现的，该类除了线程数以外，还有两个地方需要注意，一个是构造器参数中的taskQueue，如果定义的是一个*队列，当线程处理速度小于task添加速度时，很容易造成内存泄漏；第二个是关闭线程池时的两个方法，shutdown()和shutdownNow(),相关资料请自行查阅。
乐观锁策略
上面所述都是基于synchronized关键字来讲的，可以看到synchronized是悲观锁，在每次操作数据前必须先拿到锁。
与悲观锁相对的是乐观锁，乐观锁就是在每次操作数据前都假设没有冲突，当执行过程中遇到了再做处理。
在java中，AutomicXx和ReentrantLock都是通过CAS实现的，CAS即CompareAndSwap，一种同步非阻塞的无锁算法，通过阅读源码，很容易理解。
具体过程有3个步骤：
1. 从内存中获取旧的值V
2. 通过旧的值V计算出新的值A
3. 将内存中的值B与V比较，如果相同，则将其修改成A，否则跳到第1步
CAS操作可以通过CPU的单条指令来完成，理论上来说效率是非常高的，但是在大量的线程频繁修改的情况下，单条线程长时间循环比较，此时CAS的表现就不尽人意了。
另外可以看到，CAS保证的是单个变量的原子性。
还有很多文章在聊AtomicXx的时候说到ABA问题，ABA问题简单来说就是一个值从A修改成B，再从B修改回A。而某些场景下，一个合理的操作不仅依赖于结果，同时依赖于过程。单独谈CAS的时候，提起ABA是没有问题的，可是在阐述AtomicXx等内容时，莫名其妙来这么一句，让人不知所以。我倒是觉得可以将CAS理解为一个最终一致性的乐观锁。
其实在ABA问题上，java也提供了支持，与AtomicReference相对的AtomicStampedReference，通过一个版本号来保证了执行顺序。
有任何问题或者发现文章中的错误之处，欢迎私信或者邮箱过来，谢谢。
公主号搜索：以镒称铢