java并发编程的艺术——第一章总结
并发编程的挑战
1.1上下文切换
- 1.1.1多线程一定快吗
- 1.1.2测试上下文切换次数和时长
- 1.1.3如何减少上下文切换
- 1.1.4减少上下文切换实战
支持多线程的处理器不论核心数目都支持多线程执行代码（单核心当然也支持）。
多线程实现机制：CPU给每个线程分配CPU时间片实现。
时间片：CPU分配给各个线程的时间。
注：因为时间片很短，所以CPU通过不停地切换线程来执行，让我们感觉到多线程是同时执行的，时间片一般是几十毫秒（ms）
CPU通过时间片分配算法来循环执行任务，当切换任务时，会保存上一个任务的状态，切换任务后也会加载当前任务的状态。
上下文切换：任务从保存到再加载的过程就是一次上下文切换。
由于有加载状态与保存状态的机制存在，上下文切换实际上会影响多线程的执行速度。
1.1.1多线程一定快吗
从文章示例看是不一定的：即当并发执行次数较少（少于百万级别），速度较串行执行慢，出现这样的情况是由于：线程的创建与上下文切换的开销。
1.1.2测试上下文切换次数和时长
从文章示例看：上下文切换大概一秒进行1000多次。
使用Lmbench3测量上下文切换的时长，使用vmstat测量上下文切换的次数
注：CS（Content Switch）表示上下文切换的次数。
1.1.3如何减少上下文切换
方法：无锁并发编程、CAS算法、使用最少线程和使用协程。
无锁并发编程：多线程竞争锁时，会引起上下文切换，所以在多线程处理数据时可以使用一些办法来避免使用锁。
将数据的ID按照Hash算法取模分段，不同的线程处理不同段的数据。
CAS算法：java中的Atomic包使用CAS算法来更新数据，而不需要加锁。
使用最少线程：避免创建不必要的线程，比如任务较少时，创建很多线程来处理，这样会导致大量线程处于等待状态。
协程：在单线程里实现多任务的调度，并在单线程里维持多个任务间的切换。（这个协程这里看不懂）。
1.1.4减少上下文切换实战
这里就变到命令行操作了。具体的我就不沾了，讲一下优化思路。
通过减少大量WAITING的线程，来减少上下文切换次数。
他通过命令行发现了大量的闲置线程，然后发现闲置线程是线程池中的工作线程（这里说明线程池接受的任务较少，大量线程闲置），然后找到配置文件修改了线程的最大数量，然后重启线程池。
WAITING线程少了系统上下文切换的次数就会少，因为每一次从WAITING到RUNNABLE都会进行一次上下文切换。
1.2死锁
首先死锁是工具，运用场景多，但是导致的问题是，一旦死锁，系统功能不可用。
写了一段代码演示死锁，代码不沾了，记住死锁的核心原因：不同线程等待不可能释放的锁。
一旦出现死锁，只能dump线程查看到底哪个线程出了问题（这里需要专门做一次dump线程的笔记）。
死锁问题很严重，常用的避免方式：
1）避免一个线程同时获取多个锁
2）避免一个线程在锁内同时占用多个资源，尽量保证每个锁只占用一个资源
3）尝试使用定时锁，使用lock.tryLcok(timeout)来替代使用内部锁机制。
4）对于数据库锁，加锁和解锁必须在一个数据库连接里，否则就会出现解锁失败的情况。
1.3资源限制的挑战
资源限制：程序的执行受限于计算机硬件资源或软件资源。
硬件资源限制：带宽的上传/下载速度，硬盘读写速度和CPU处理速度。 软件资源限制：数据库连接数和socket连接数。
引发的问题：程序将串行执行的部分改为并行执行后，由于资源限制还是并行执行，导致了不仅不快反而更慢（上下文切换，资源的调度都需要时间）。
如何解决：
硬件资源限制可以尝试集群解决。
软件资源限制：将资源池复用。
在资源限制的情况下进行并发编程：根据资源限制调整程序的并发度。
1.4本章总结：
有可能是因为我的知识水平有限，这一章看起来除了一些理论的补充，看起来有点空洞的！
也可能是目前根本没有接触过多线程的编程吧。
不过最后作者提出了宝贵的建议：熟练使用JDK并发容器与工具类。学无止境啊。
注：本书的2、3章节由于涉及计算机与JVM的知识比较多，总结起来相对难度较大，语言也很难凝练，而且对我来说还需要很多理解所以本书从第四章开始总结，2、3章的总结会暂缓