prince~home

"数据竞争"术语很容易与另外一个相关术语"竞态条件"混淆，"数据竞争"是指，如果在访问共享的非final类型的域时没有采用同步来进行协调，那么就会出现数据竞争，当一个数据写入一个变量而另一个线程接下来读取这个变量，或者读取一个之前由另一个线程写入的变量时，并且在这两个线程之间没有使用同步，那么就可能出现数据竞争。竞态条件出现的场景：比较经典的场景就是单例模式，单例模式首先判断对象是否初始化，如果没有则初始化，并创建一个新的对象并返回一个引用，从而在后台的调用中无须再执行这段高开销的代码。

也就是说当future的状态>COMPLETING时候调用get方法才会返回，而明显DiscardPolicy策略在拒绝元素的时候并没有设置该future的状态，后面也没有其他机会可以设置该future的状态，所以future的状态一直是NEW，所以一直不会返回，同理DiscardOldestPolicy策略也是这样的问题，最老的任务被淘汰时候没有设置被淘汰任务对于future的状态，也会导致一直不会返回。线程池被创建后如果没有任务过来，里面是不会有线程的。线程池被创建后里面有线程吗？

案例承继自上一章echo服务端案例：相比于 Thread-Per-Message 模式的实现，改动非常少，仅仅是创建了一个最多线程数为 500 的线程池 es，然后通过 es.execute() 方法将请求处理的任务提交给线程池处理。优势：可以避免无限制的创建线程导致OOM；并且可以避免无限制的接收任务导致OOM。Worker Thread模式及其实现。如何避免重复创建线程？

Thread-Per-Message模式：为每个任务分配一个独立的线程。经典应用：网络编程里服务端的实现（服务端为每个客户端请求创建一个独立的线程，当线程处理完请求后，自动销毁）。用 Thread 实现 Thread-Per-Message 模式（这个实现用于对比，很坑）如何理解 Thread-Per-Message 模式（委托代办）Fiber 实现 Thread-Per-Message 模式。最简单实用的分工方法。

对于当前值小于当前工作线程数的情况，说明有多余的worker线程，此时会向当前idle的worker线程发起中断请求以实现回收，多余的worker在下次idel的时候也会被回收；对于包含I/O操作或其他阻塞操作的任务，由于线程不会一直执行，因此线程池的规模应该更大，要正确地设置线程池的大小，需估算出任务的等待时间与计算时间的比值，这种估算不需要很精确。可以把它当做一个备份线程就好。而且，你再品一品 JDK 的源码，其实源码也体现出了有修改的含义的，两个值去做差值，只是第一次设置的时候原来的值为 0 而已。

也就是说当future的状态>COMPLETING时候调用get方法才会返回，而明显DiscardPolicy策略在拒绝元素的时候并没有设置该future的状态，后面也没有其他机会可以设置该future的状态，所以future的状态一直是NEW，所以一直不会返回，同理DiscardOldestPolicy策略也是这样的问题，最老的任务被淘汰时候没有设置被淘汰任务对于future的状态，也会导致一直不会返回。运行后发现程序能正常退出。那么默认的AbortPolicy策略为啥没问题那？

从运行结果看在任务one阻塞的5s内，主线程执行到了代码(5)等待任务one执行完毕，当任务one执行完毕后代码（5）返回，主线程打印出task one finish null。之后线程池的唯一线程会去队列里面取出任务two并执行所以输出start runable two然后代码（6）会返回，这时候主线程输出task two finish null，然后执行代码（7）等待任务three执行完毕，从执行结果看代码（7）会一直阻塞不会返回。再向线程池提交了一个任务two，这时候会把任务two放入到阻塞队列；

线程池被创建后如果没有任务过来，里面是不会有线程的。allowCoreThreadTimeOut 该值默认为 false。核心线程数会被回收吗？

前面我们提到第一个Attach Listener线程的职责是接收外部jvm命令，当命令接收成功后，会交给signal dispather线程去进行分发到各个不同的模块处理命令，并且返回处理结果。这个线程也是在main线程之后创建的，其优先级为10，主要用于在垃圾收集前，调用对象的finalize()方法；该线程也是daemon线程，因此如果虚拟机中没有其他非daemon线程，不管该线程有没有执行完finalize()方法，JVM也会退出；只有当开始一轮垃圾收集时，才会开始调用finalize()方法；

还有一种方式，破坏循环等待方式，破坏这个条件，需要对资源进行排序，然后按序申请资源。这个实现非常简单，我们假设每个账户都有不同的属性 id，这个 id 可以作为排序字段，申请的时候，我们可以按照从小到大的顺序来申请。4.循环等待，线程 T1 等待线程 T2 占有的资源，线程 T2 等待线程 T1 占有的资源，就是循环等待。2.占有且等待，线程 T1 已经取得共享资源 X，在等待共享资源 Y 的时候，不释放共享资源 X；必须同时获取到XY两个资源，才能进行同步，这样便解决了循环依赖等待的情况。

最后，一定要记得，shutdownNow和shuwdown调用完，线程池并不是立马就关闭了，要想等待线程池关闭，还需调用awaitTermination方法来阻塞等待。如果线程池阻塞等待从队列里读取任务，则会被唤醒，但是会继续判断队列是否为空，如果不为空会继续从队列里读取任务，为空则线程退出。shutdownNow方法的解释是：线程池拒接收新提交的任务，同时立马关闭线程池，线程池里的任务不再执行。shutdown方法的解释是：线程池拒接收新提交的任务，同时等待线程池里的任务执行完毕后关闭线程池。

Java 提供了 CopyOnWriteArrayList，为什么没有提供 CopyOnWriteLinkedList 呢？Copy-on-Write 模式的应用领域。

问题：如果具备不可变性的类，需要提供类似修改的功能，创建一个新的不可变对象就行了，这是与可变对象的一个重要区别，可变对象往往是修改自己的属性。所有的修改操作都创建一个新的不可变对象：这样会不会造成创建的对象太多了，有点太浪费内存呢？Foo 具备不可变性，线程安全，但是类 Bar 并不是线程安全的，类 Bar 中持有对 Foo 的引用 foo，对 foo 这个引用的修改在多线程中并不能保证可见性和原子性。本意是 A 用锁 al，B 用锁 bl，各自管理各自的，互不影响。快速实现具备不可变性的类。

多线程下，维护一个共享状态满足某个条件时，执行业务逻辑；当不满足时则立即放弃。通常用互斥锁来确保共享状态线程安全，如果不需要保证共享状态原子性，也可以用 volitle 修饰，替换互斥锁。Balking 模式本质上是一种规范化地解决“多线程版本的 if”的方案，其实就是对if判断的加锁设计。并抽象一个方法出来。使用 volatile 的前提是对原子性没有要求。用 volatile 实现 Balking 模式。Balking 模式的经典实现。这样的好处是将并发处理逻辑和业务逻辑分开。Balking 模式。

概述：多线程下，A线程有个受保护的操作，在执行过程中需要等待满足某个条件，这个条件由B线程控制，条件不满足，A线程则挂起，直到条件满足才继续执行。例子：核心是：get() 方法通过条件变量的 await() 方法实现等待，onChanged() 方法通过条件变量的 signalAll() 方法实现唤醒功能。单线程场景中，if 语句是不需要等待的，因为在只有一个线程的条件下，如果这个线程被阻塞，那就没有其他活动线程了，这意味着 if 判断条件的结果也不会发生变化了。”来理解这个模式会更简单。

1.任务性质不同的任务可以用不同规模的线程池分开处理，程序密集型任务尽量配置少的线程数量，入Ncpu+1的线程，Ncpu是cpu核心数。混合任务，如果可以拆分，拆分成一个程序密集型任务和一个io密集型任务，只要两任务的执行时间不是相差太大，拆分后的吞吐率更高，用各自的线程池去做；4.依赖数据库连接的任务，因为线程提交sql后需要等待数据库返回执行结果（数据库io，数据网络传输），如果时间越长，cpu空闲时间越长，此线程堵塞时间越长，那么就应该设置更多的线程，充分利用cpu。3.任务的执行时间：长、中、短。

输出解释 CPU以及CPU0、CPU1、CPU2、CPU3每行的每个参数意思（以第一行为例）为： 参数解释 user (432661) 从系统启动开始累计到当前时刻，用户态的CPU时间（单位：jiffies），不包含nice值为负的进程。“intr”这行给出中断的信息，第一个为自系统启动以来，发生的所有的中断的次数；它的单位随硬件平台的不同而不同。在Linux/Unix下，CPU利用率分为用户态，系统态和空闲态，分别表示CPU处于用户态执行的时间，系统内核执行的时间，和空闲系统进程执行的时间。

上面说过，cpu的工作效率要高于磁盘，而进程在cpu上面运行需要访问磁盘文件，这个时候cpu会向内核发起调用文件的请求，让内核去磁盘取文件，这个时候会切换到其他进程或者空闲，这个任务就会转换为不可中断睡眠状态。当在数据特别大的时候，如果执行的sql语句没有索引，就会造成扫描表的行数过大导致I/O阻塞，或者是语句中存在死锁，也会造成I/O阻塞，从而导致不可中断睡眠进程过多，导致负载过大。在上面的进程状态变换过程中，除了running状态，其他都是等待状态，那么其他状态都会加入到负载等待进程中吗？

产生的原因一句话总结就是：等待磁盘I/O完成的进程过多，导致进程队列长度过大，但是cpu运行的进程却很少，这样就体现到负载过大了，cpu使用率低。下面内容是具体的原理分析：在分析负载为什么高之前先介绍下什么是负载、多任务操作系统、进程调度等相关概念。什么是负载：负载就是cpu在一段时间内正在处理以及等待cpu处理的进程数之和的统计信息，也就是cpu使用队列的长度统计信息，这个数字越小越好（如果超过CPU核心*0.7就是不正常）负载分为两大部分：CPU负载、IO负载。