Java并发成神之路——JUC全方位详解

synchronized

Lock接口的相关类

Collections.synchronizedList(new ArrayList())等

Vector等

Atomic*基本类型原子类

Atomic*Array数组类型原子类（数组里的元素，都可以保证原子性）

Atomic*Reference引用类型原子类

Atomic*FieldUpdater升级原子类

Adder加法器

Accumulator累加器

ConcurrentHashMap

CopyOnWriteArrayList

并发队列

ConcurrentSkipListMap和ConcurrentSkipListSet

ThreadLocal

栈封闭

ThreadLocal

栈封闭

使用各种互斥同步的锁

使用同步的工具类

ConcurrentHashMap

CopyOnWriteArrayLis

并发队列

ConcurrentSkipListMap和ConcurrentSkipListSet

Atomic*基本类型原子类

Atomic*Array数组类型原子类（数组里的元素，都可以保证原子性）

Atomic*Reference引用类型原子类

Atomic*FieldUpdater升级原子类

Adder加法器

Accumulator累加器

FixedThreadPool

CachedThreadPool

ScheduledThreadPool

SingleThreadExecutor

ForkJoinPool

...

corePoolSize指核心线程数：
线程池在完成初始化后，默认情况下，线程池内并无任何线程，
线程池会等待有任务到来时，在创建新线程去执行任务

maxPoolSize：
线程池有可能会在核心线程数的基础上，额外增加一些线程，
但是这些新增的线程数有一个上限，这就是最大量maxPoolSize

添加线程的规则

增减线程的特点

新的线程是由ThreadFactory创建的,默认使用Executors.defaultThreadFactory() ,
创建出来的线程都在同一个线程组,拥有同样的NORM_PRIORITY优先级并且都不是守护线程。
如果自己指定ThreadFactory,那么就可以改变线程名、线程组、优先级、是否是守护线程等。

直接交接

无界队列

有界的队列

newFixedThreadPool

newSingleThreadExecutor

CachedThreadPool

ScheduledThreadPoool

核心方法纵览

彩蛋：如何快速查看继承关系图

Executor

ExecutorService

Executor和ExecutorService的区别

Executors

线程重用的核心是，线程池对Thread做了包装，不重复调用hread.start()，而是自己有一个Runnable.run()，run方法里面循环在跑，跑的过程中不断检查我们是否有新加入的子Runnable对象，有新的Runnable进来的话就调一下我们的run()，其实就一个大run()把其它小run()#1,run()#2,...给串联起来了。同一个Thread可以执行不同的Runnable，主要原因是线程池把线程和Runnable通过BlockingQueue给解耦了，线程可以从BlockingQueue中不断获取新的任务。

源码解读

只锁必要的操作数据的部分，把其他不相关的、开销大的、可能被阻塞的操作，例如IO操作，通通移出互斥的范围。

当然，也不能过分小，原子操作必须包含到一个同步块中。

方法这个级别太高了、范围太宽了。如果我们锁住方法，很有可能其实我们并不需要这么大锁的范围，我们可以把这个锁住方法的锁优化成代码块，代码会锁住的部分往往比方法要小。

如果只看这个标题，同学们可能会很困惑，我明明是有请求锁的需求，你凭什么让我减少次数呢？如果我减少次数的话，是不是就无法保证线程安全了呢？实际情况不总是这样的，有的时候我们可以通过减少请求锁的次数来优化性能，让我们来举一个具体的非常好的例子：

在很多日志框架里。最主要的思路是把系统的打印日志的能力进行一系列包装，比如说可以设置打印的级别设置、格式等等。

但是对于日志框架，有一个很重要的点，那就是当多个线程同时进行日志打印的时候，可能如果只是采用刚才的那种简单的架构设计，那么多个线程同时打印便会造成线程竞争，因为这是一个IO操作，多个线程需要操作同一个日志文件，需要加锁。

这里我们对架构进行改进，把多个线程的打印日志的这种需求收集到一起，然后统一由某一个线程去执行写入文件的操作，这样的话便不会有过多的锁的竞争的情况，可以大大提高打印日志的效率，我们相当于是使用了一个消息队列来作为我们的中间层，这也是我们现有的优质日志框架Lof4j2的一个思路。

这里的“热点”，指的是一个大家都想同时访问的，并且需要互斥同步的资源。有的时候。我们会人为制造出这种资源，从而导致了性能的下降。

比如一个典型的例子就是在HashMap中，size()方法是获取到当前容器大小，size的第一种实现方式是每次调用size方法的时候，就去遍历一遍，但是这样的时间复杂度是O(n)。

所以就有一种优化方法是，每一次增加元素的时候，比如put方法，我就去更新计数器，这样一来，如果需要知道集合的大小，我只需要读取一下之前已经更新过的数值就可以了，把复杂度降到了O(1)，这是一个很不错的优化。

可是这有一个问题，那就是如果并发地去放置元素，就会导致这个计数器被多线程同时使用，也就带来了性能问题，因为多个线程需要去竞争锁。

一个相当不错的解决方案是，在JDK7的ConcurrentHashMap中，不同的segment之间不共用同一个计数器，而仅仅是在最终真正需要获取集合容量的时候，再把多个计数器的值相加，这样的思维，我们在之前的LongAdder中已经分析过了，是一种非常好的思路，可以大大提高并发的能力。

否则很容易死锁，演示一个死锁的例子，之前写过

不同的锁适合不同的场景。放弃互斥锁，可以提高并发性能。

被final修饰的变量，意味着值不能被修改。如果变量是对象，那么对象的引用不能变，但是对象自身的内容依然可以变化。

final instance variable（类中的final属性）

final static variable（类中的static final属性）

final local variable（方法中的final变量）

属性被声明为final后，该变量则只能被赋值一次。且一旦被赋值，final的变量就不能再被改变，如论如何也不会变。直到海角天涯也不会变心，非常好的品质

final instance variable（类中的final属性）

final static variable（类中的static final属性）

final local variable（方法中的final变量）

我们来思考一下为什么语法要这继承这样？：如果初始化不赋值，后续赋值，就是从null变成你的赋值，这就违反final不变的原则了！

Collections.synchronizedMap()是线程安全的，但是它是通过使用一个全局的锁来同步不同线程间的并发访问，因此会带来较大的性能问题。

同时put碰撞导致数据丢失

同时put扩容导致数据丢失

死循环造成的CPU100%

彩蛋：调试技巧——如何修改JDK版本，从8到7

彩蛋：调式技巧——多线程配合，模拟真实场景

HashMap在高并发下的死循环（仅在JDK7及以前存在）

红黑树是每个节点都带有颜色属性的二叉查找树，本质是对二叉查找树BST的一种平衡策略，颜色为红色或黑色。

我们理解为是一种平衡二叉查找树就可以，查找效率高，会自动平衡，防止极端不平衡从而影响查找效率的情况发生。

Java 7中的ConcurrentHashMap最外层是多个segment，每个segment的底层数据结构与HashMap类似，仍然是数组和链表组成的拉链法。

每个segment独立上ReentrantLock锁，每个segment之间互不影响，提高了并发效率。

ConcurrentHashMap 默认有 16 个 Segments，所以最多可以同时支持 16 个线程并发写（操作分别分布在不同的 Segment 上）。这个默认值可以在初始化的时候设置为其他值，但是一旦初始化以后，是不可以扩容的。

黑名单，每日更新

监听器：迭代操作远多余修改操作

读读共享、其他都互斥（写写互斥、读写互斥、写读互斥）

读取是完全不用加锁的，并且更厉害的是：写入也不会阻塞读取操作。只有写入和写入之间需要进行同步等待

因为CopyOnWrite的写是复制机制，所以在进行写操作的时候，内存里会同时驻扎两个对象的内存。

CopyOnWrite容器只能保证数据的最终一致性，不能保证数据的实时一致性。所以如果你希望写入的的数据，马上能读到，请不要使用CopyOnWrite容器。

底层是数组

get操作都没有加锁，保证了读取操作的高速。

在添加的时候就上锁，并复制一个新数组，增加操作在新数组上完成，将array指向到新数组中，最后解锁。

执行迭代操作的时候，操作的都是原数组，而原数组不会被修改（修改都会去修改副本数组），所以执行迭代操作不需要加锁，也不会抛异常。

容量Integer.MAX_VALUE

SynchronousQueue首先是一个阻塞队列，然后不同之处在于，它的容量为0 ，所以没有一个地方来暂存元素，导致每次取数据都要先阻塞，直到有数据被放入；同理，每次放数据的时候也会阻塞，直到有消费者来取。

需要注意的是，SynchronousQueue的容量不是1而是0，因为SynchronousQueue不需要去持有元素，它所做的就是直接传递（direct handoff）。

每当需要传递的时候，SynchronousQueue会把元素直接从生产者传给消费者，在此期间并不需要做存储，所以效率很高

1. SynchronousQueue没有peek等函数，因为peek的含义是取出头结点，但是SynchronousQueue的容量是0，所以连头结点都没有，也就没有peek方法。

2. 同理，没有iterate相关方法。

3. 是一个极好的用来直接传递的并发数据结构。

4. SynchronousQueue是线程池Executors.newCachedThreadPool()使用的阻塞队列。

AQS

这里对CountDownLatch类里面最重要的3个方法进行分析

构造方法

await()

countDown()

new Semaphore(int permits, boolean fair)

tryAcquire()

tryAcquire(timeout)

availablePermits

acquire()

acquireUninterruptibly()

release()

一次性获取或释放多个许可证

signalAll()会唤起所有的正在等待的线程。

但是signal()是公平的，只会唤起那个等待时间最长的线程，在当前情况下，是thread-0。

获取操作会依赖state变量，经常会阻塞（比如获取不到的时候）。

在Semaphore中，获取就是acquire方法，作用是获取一个许可证；而在CountDownLatch里面，获取就是await方法，作用是“等待，直到倒数结束”。

释放操作不会阻塞，在Semaphore中，释放就是release方法，作用是释放一个许可证；CountDownLatch里面，获取就是countDown方法，作用是“倒数1个数”。

在我们刚才讲的获取/释放方法中，里面需要调用继承了AQS的Sync类的acquire和release（独占锁例如ReentrantLock就是acquire和release，共享锁比如CountDownLatch就是acquireShared和releaseShared）方法，这里需要我们实现的方法，根据业务逻辑不同，有不同的实现。

public CountDownLatch(int count) { if (count < 0) throw new IllegalArgumentException("count < 0"); this.sync = new Sync(count);}

可以看出，这里给Sync赋值了count，看到Sync的构造函数，正是给state变量去赋值了：

Sync(int count) { setState(count);}

所以在CountDownLatch里面的state，就是代表我们希望它倒数的次数。

一步步看看出最后还是去获取state变量的值。

这个就是“释放”方法，会调用到CountDownLatch重写的tryReleaseShared方法，分析tryReleaseShared方法：

如果返回true，就释放所有之前阻塞的线程。

当state为0的时候，说明之前已经释放过了，本次就不需要重复释放了。

举例：

如果c为5，nextc就是4，这个时候state会被设置为4，但是不符合nextc == 0，所以不释放锁。

如果c为1，nextc就是0，这个时候state会被设置为0，并且符合nextc == 0，所以打开栅栏，把之前阻塞的线程通通放开。

同理，await和刚才的countDown是形成配对的，是“获取”方法，追踪源码可以看到，会调用到tryAcquireShared方法，这个方法如下：

就是看state是不是0，不为0就返回-1，所以在acquireSharedInterruptibly方法中：

就会调用doAcquireSharedInterruptibly方法，随即进入阻塞状态。

如果state已经是0了，那么就不会调用doAcquireSharedInterruptibly，线程也就不会阻塞，相当于是倒数已经结束了，立刻放行。

由于是可重入的，所以state代表重入的次数，每次释放锁，先判断是不是当前持有锁的线程释放的，如果不是就抛异常，如果是的话，重入次数就减一，如果减到了0，就说明完全释放了，于是free就是true，并且把state设置为0。