最牛并发编程总结

最大堆，父节点的键值总是大于或等于任何一个子节点的键值

最小堆，父节点的键值总是小于或等于任何一个节点的键值

key-value键值对

红黑树节点

就相当于一颗红黑树，其构造方法其实就是构造红黑树的过程

辅助节点，用于ConcurrentHashMap扩容操作

sizeCtl

ConcurrentHashMap初始化方法

只能有一个线程参与初始化过程，其他线程必须挂起

构造函数不做初始化过程，初始化真正是在put操作触发

步骤

根据hash值计算节点插入在table的位置，如果该位置为空，则直接插入，否则插入到链表或者树中

真实情况较为复杂

table为null，线程进入初始化步骤，如果有其他线程正在初始化，该线程挂起

如果插入的当前 i 位置 为null，说明该位置是第一次插入，利用CAS插入节点即可，插入成功，则调用addCount判断是否需要扩容。
若插入失败，则继续匹配（自旋）

若该节点的hash ==MOVED（-1），表示有线程正在进行扩容，则进入扩容进程中

其余情况就是按照链表或者红黑树结构插入节点，但是这个过程需要加锁（synchronized）

table ==null ；return null

从链表/红黑树节点获取

多线程扩容

步骤

红黑树是一种自平衡二叉查找树，是计算机科学领域中的一种数据结构，典型的用途是实现关联数组，存储有序的数据。
别称"对称二叉B树"，它是复杂的，但它的操作有着良好的最坏情况运行时间，并且在实践中是高效的。
它可以在O(logn)时间内做查找，插入和删除，这里的n是树的结点个数

特性

基于ReentrantLock实现分段锁来实现的segment。jdk1.7中采用Segment + HashEntry的方式进行实现

1.8中放弃了Segment臃肿的设计，取而代之的是采用Node + CAS + Synchronized来保证并发安全进行实现

由很多层结构组成，level是通过一定的概率随机产生的

每一层都是一个有序的链表，默认是升序，也可以根据创建映射时所提供的Comparator进行排序，具体取决于使用的构造方法

最底层(Level 1)的链表包含所有元素

如果一个元素出现在Level i 的链表中，则它在Level i 之下的链表也都会出

每个节点包含两个指针，一个指向同一链表中的下一个元素，一个指向下面一层的元素

创建一个可根据需要创建新线程的线程池，但是在以前构造的线程可用时将重用它们。对于执行
很多短期异步任务的程序而言，这些线程池通常可提高程序性能。调用 execute 将重用以前构造
的线程（如果线程可用）。如果现有线程没有可用的，则创建一个新线程并添加到池中。终止并
从缓存中移除那些已有 60 秒钟未被使用的线程。因此，长时间保持空闲的线程池不会使用任何资
源。

创建一个可重用固定线程数的线程池，以共享的无界队列方式来运行这些线程。在任意点，在大
多数 nThreads 线程会处于处理任务的活动状态。如果在所有线程处于活动状态时提交附加任务，
则在有可用线程之前，附加任务将在队列中等待。如果在关闭前的执行期间由于失败而导致任何
线程终止，那么一个新线程将代替它执行后续的任务（如果需要）。在某个线程被显式地关闭之
前，池中的线程将一直存在。

创建一个线程池，它可安排在给定延迟后运行命令或者定期地执行。

Executors.newSingleThreadExecutor()返回一个线程池（这个线程池只有一个线程）,这个线程
池可以在线程死后（或发生异常时）重新启动一个线程来替代原来的线程继续执行下去！

corePoolSize

maximumPoolSize

keepAliveTime

unit

workQueue

threadFactory

handler

Executor.execute()

ExecutorService.submit()

要想合理地配置线程池，就必须首先分析任务特性，可以从以下几个角度来分析。

任务的性质：CPU密集型任务、IO密集型任务和混合型任务
任务的优先级：高中低
任务的执行时间：长中短
任务 的依赖性;是否依赖其他系统资源

CPU密集型任务应配置尽可能小的线程，如配置NCPU+1个线程的线程池，
IO密集型任务线程并不是一直在执行任务 ，则应配置尽可能多的线程，如2*NCPU 。

可以通过Runtime.getRuntime().availableProcessors()方法获得当前设备的CPU个数
优先级不同的任务可以使用优先级队列PriorityBlockingQueue来处理，它可以让优先级高的任务先执行。

在监控线程池的时候可以使用以下属性：
taskCount: 线程池需要执行的任务数量
completedTaskCount: 线程池在 运行过程中已完成的任务数量，小于或等于taskCount。
getPoolSize;线程池的线程数量，如果线程池不销毁的话，线程池里的线程不会自动销毁，所以这个大小只增不减
getActiveCount； 获取活动的线程数

提供操作

实现RunnableFuture接口，即可以作为Runnable被执行，也可以
作为Future得到Callable的返回值

内部基于AQS实现

程序运行结束，线程自动结束。

一般 run()方法执行完，线程就会正常结束，然而，常常有些线程是伺服线程。它们需要长时间的
运行，只有在外部某些条件满足的情况下，才能关闭这些线程。使用一个变量来控制循环，例如：
最直接的方法就是设一个boolean 类型的标志，并通过设置这个标志为 true或 false 来控制 while
循环是否退出。
定义了一个退出标志 exit，当 exit 为 true 时，while 循环退出，exit 的默认值为 false.在定义 exit
时，使用了一个 Java 关键字 volatile，这个关键字的目的是使 exit 同步，也就是说在同一时刻只
能由一个线程来修改 exit 的值。

线程处于阻塞状态：如使用了 sleep,同步锁的 wait,socket 中的 receiver,accept 等方法时，
会使线程处于阻塞状态。当调用线程的 interrupt()方法时，会抛出 InterruptException 异常。
阻塞中的那个方法抛出这个异常，通过代码捕获该异常，然后 break 跳出循环状态，从而让
我们有机会结束这个线程的执行。通常很多人认为只要调用 interrupt 方法线程就会结束，实
际上是错的， 一定要先捕获 InterruptedException 异常之后通过 break 来跳出循环，才能正
常结束 run 方法。

线程未处于阻塞状态：使用 isInterrupted()判断线程的中断标志来退出循环。当使用
interrupt()方法时，中断标志就会置 true，和使用自定义的标志来控制循环是一样的道理。

程序中可以直接使用 thread.stop()来强行终止线程，但是 stop 方法是很危险的，就象突然关
闭计算机电源，而不是按正常程序关机一样，可能会产生不可预料的结果，不安全主要是：
thread.stop()调用之后，创建子线程的线程就会抛出 ThreadDeatherror 的错误，并且会释放子
线程所持有的所有锁。一般任何进行加锁的代码块，都是为了保护数据的一致性，如果在调用
thread.stop()后导致了该线程所持有的所有锁的突然释放(不可控制)，那么被保护数据就有可能呈
现不一致性，其他线程在使用这些被破坏的数据时，有可能导致一些很奇怪的应用程序错误。因
此，并不推荐使用 stop 方法来终止线程。

在单线程环境下不能改变程序运行的结果

存在数据依赖关系的不允许重排序

如果两个操作访问统一变量，且这两个操作有一个是写操作，此时这两个操作之间就存在数据依赖性，

写一个变量之后，再读一个变量

写一个变量之后，再写一个变量

读一个变量后，再写一个变量

一个线程中的所有操作必须按照程序的顺序来执行

所有线程都只能看到一个单一的操作执行顺序，不管程序是否同步

每个操作都必须原子执行且立刻对所有线程可见

如果一个操作happens-before另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行熟悉怒排在第二个操作之前。
两个操作之间存在happens-before关系，并不意味java平台的具体实现必须按照happens-before关系指定的顺序来执行。如果重排序后的执行结构，与按happens-before关系来执行的结果一致，那么这种重排序并不非法(JMM允许这种重排序）
as-if-serial语义保证单线程内程序的执行结果不被改变，happens-before关系保证正确同步的多线程程序的执行结构不被改变。

synchronized的锁就是保存在Java对象头中的

包括两部分数据

monitorenter

monitorexit

初始时为NULL表示当前没有任何线程拥有该monitor record，当线程成功拥有该锁后保存线程唯一标识，当锁被释放时又设置为NULL

标记方式

自旋方式

适应性自旋

阻塞方式

若不存在数据竞争的情况，JVM会消除锁机制

判断依据:变量逃逸

将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁。例如for循环内部获取锁

对任意(包括64位long类型和double类型)单个volatile变量的读/写具有原子性。但是类似于a++这种复合操作不具有原子性。

（最重要的特性）。当一个被volatile关键字修饰的变量被一个线程修改的时候，其他线程可以立刻得到修改之后的结果。当一个线程向被volatile关键字修饰的变量写入数据的时候，虚拟机会强制它被值刷新到主内存中。当一个线程用到被volatile关键字修饰的值的时候，虚拟机会强制要求它从主内存中读取。

指令重排序是编译器和处理器为了高效对程序进行优化的手段，它只能保证程序执行的结果时正确的，但是无法保证程序的操作顺序与代码顺序一致。这在单线程中不会构成问题，但是在多线程中就会出现问题。非常经典的例子是在单例方法中同时对字段加入voliate，就是为了防止指令重排序。

当写一个Volatile 变量的时候，JMM会把该线程对应的本地内存的共享变量刷新到主内存中. 使用上面的代码中示例，
当在执行writer() 方法 写了flag变量后，JMM会立即可本地内存的共享变量刷新到主内存中。

当读取一个volatile变量的时候，JMM会将当前线程的本地内存共享变量设置为无效，线程在接下来的操作，会从主内存中读取共享变量。

获取锁

释放锁

获取锁

释放锁

是用来创建和其他同步类的基本线程阻塞原语

每个使用LockSupport的线程都会与一个许可关联，如果该许可可用，并且可在进行中使用，则调用park()将立即返回，否则可能阻塞。
如果许可尚不可用，则可以调用unpark使其可用。

park()和unpark()

自旋CAS如果长时间不成功，会给CPU带来非常大的执行开销

当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子
性，这个时候就可以用锁。还有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如，有两个共享变量i＝2，j=a，合并一下ij=2a，然后用CAS来操作ij。从Java 1.5开始，JDK提供了AtomicReference类来保证引用对之间的原子性，就可以把多个变量放在一个对象里来进行CAS操作。

因为CAS需要在操作值的时候，检查值有没有发生变化，如果没有发生变化则更新，但是如果一个值 原来是A，变成了B，又变成了B，那么使用CAS进行检查时会发现它的值没有发生变化，但是实际上却变化了。

解决办法

返回此线程局部变量的当前线程副本中的值

返回此线程局部变量的当前线程的值

移除此线程局部变量当前线程的值

将此线程局部变量的当前线程副本中的值设置为指定值

key弱引用，value强引用，无法回收

执行任务的线程池

表示任务，用于ForkJoinPool的任务抽象

执行任务的工作现场