【并发编程挑战】死锁
死锁定义死锁是进程死锁的简称，是由Dijkstra于1965年研究银行家算法时首先提出来的。是指多个进程循环等待它方占有的资源而无限期地僵持下去的局面。系统发生死锁现象不仅浪费大量的系统资源，甚至导致整个系统崩溃，带来灾难性后果。
产生死锁原因
系统资源不足
进程推进顺序不当
资源分配不合理
死锁产生的必要条件
互斥条件：一个资源只能被一个进程或者线程使用。
请求和保持条件：一个进程或者线程，请求资源的时候发生阻塞，对已经获取的资源保持不放。
不可剥夺条件：进程或者线程以获得的资源，在未使用完成时，不能强行剥夺。
循环等待条件：若干进程或者线程形成一种头尾相接的循环等待的资源关系。
这四分条件是死锁产生的必要条件，只要发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。
如何避免死锁
以确定的顺序获得锁
加锁时限Lock接口提供了boolean tryLock(long time, TimeUnit unit) throws InterruptedException方法，该方法可以按照固定时长等待锁，因此线程可以在获取锁超时以后，主动释放之前已经获得的所有的锁。
...
【并发编程挑战】上下文切换
引言上下文切换（有时也称做进程切换或任务切换）是指 CPU 从一个进程或线程切换到另一个进程或线程。上下文切换会影响多线程执行速度。
上下文定义cpu发生进程或者线程切换时，所依赖的数据集合，比如一个函数有外部变量，函数运行时，必须获取外部变量，这些变量值的集合就是上下文。
引发问题对于CPU密集型任务，多线程处理会发生上下文切换，会影响到执行速度，如果时IO密集型，多线程技术优点尽显。
如何减少上下文切换
无锁并发编程，锁的获取与释放会发生上下文切换，多线程时会影响效率。无锁并发编程就是将数据分块，每个线程处理各自模块。比如LongAdder中部分代码。
CAS算法，并发编程时通过CAS算法更新数据，而不必加锁。如Java的atomic包下的工具类。
使用最少线程，减少不必要的线程创建，自定义线程池。
使用协程，在单线程中维护多任务调度，处理任务间切换，Golang对于协程的使用貌似很强大。
JAVA并发容器源码分析【四】LinkedBlockingQueue源码翻译
基于JDK8，LinkedBlockingQueue源码翻译
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441451461471481491501511521531541551561571581591601611621631641651661671681691701711721731741751761771781791801811821831841851861871881891901911921 ...
JAVA并发容器源码分析【四】LinkedBlockingQueue的API源码分析
简单介绍一下LinkedBlockingQueue中API的源码，如构造方法，新增，获取，删除，drainTo。
构造函数LinkedBlockingQueue有三个构造方法，其中无参构造尽量少用，因为容量为Integer的最大值，操作不当会出现内存溢出。
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960/** * Creates a {@code LinkedBlockingQueue} with a capacity of * {@link Integer#MAX_VALUE}. * 创建一个容量为Integer最大值的LinkedBlockingQueue */ public LinkedBlockingQueue() { this(Integer.MAX_VALUE); } /** * Crea ...
JAVA并发容器源码分析【四】LinkedBlockingQueue简单分析
定义与性质
LinkedBlockingQueue是一个阻塞队列，内部由两个ReentrantLock来实现出入队列的线程安全，由各自的Condition对象的await和signal来实现等待和唤醒功能。
基于单向链表的、范围任意的（其实是有界的）、FIFO 阻塞队列。
头结点和尾结点一开始总是指向一个哨兵的结点，它不持有实际数据，当队列中有数据时，头结点仍然指向这个哨兵，尾结点指向有效数据的最后一个结点。这样做的好处在于，与计数器 count 结合后，对队头、队尾的访问可以独立进行，而不需要判断头结点与尾结点的关系。
节点与属性123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778/** * Linked list node class * 链表节点内部类 */static class Node<E> { //节点 ...
JAVA并发容器源码分析【三】CopyOnWriteArrayList源码分析
定义CopyOnWrite容器即写时复制的容器。当我们往容器添加元素的时候，先将当前容器进行Copy，复制出一个新的容器，然后新的容器里添加元素，添加完元素之后，再将原容器的引用指向新的容器。
优缺点优点：读操作性能很高，比较适用于读多写少的并发场景。Java的list在遍历时，若中途有别的线程对list容器进行修改，则会抛出ConcurrentModificationException异常。而CopyOnWriteArrayList由于其”读写分离”的思想，遍历和修改操作分别作用在不同的list容器，所以在使用迭代器进行遍历时候，也就不会抛出ConcurrentModificationException异常。
缺点：
内存占用问题，执行写操作时会发生数组拷贝
无法保证实时性，Vector对于读写操作均加锁同步，可以保证读和写的强一致性。而CopyOnWriteArrayList由于其实现策略的原因，写和读分别作用在新老不同容器上，在写操作执行过程中，读不会阻塞但读取到的却是老容器的数据。
使用场景CopyOnWrite并发容器用于读多写少的并发场景。比如白名单，黑名单，商品类目的访 ...
JAVA并发容器源码分析【三】CopyOnWriteArrayList源码翻译
基于JDK1.8的CopyOnWriteArrayList的简单翻译：
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213313413513613713813914014114214314414514614714814915015115215315415515615715815916016116216316416516616716816917017117217317417517617717817918018118218318418518618718818919019 ...
JAVA并发容器源码分析【二】ConcurrentHashMap分析之扩容
扩容触发条件：
treeifyBin方法中将链表转换成红黑树时判断table数组的长度是否小于阈值（64），如果小于就进行扩容而不是树化。
putAll方法中，会根据size大小扩容。
putVal在计数的时候，判断当前Entry数量是否超过阈值，如果超过就进行扩容
与扩容相关的常量、变量与函数123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899 /** * Minimum number of rebinnings per transfer step. Ranges are * subdivided to allow multiple resizer threads. This value * serves as a lower bound to avoi ...
JAVA并发容器源码分析【二】ConcurrentHashMap分析之初始化
JDK8的ConcurrentHashMap的初始化源码及注释：
123456789101112131415161718192021222324252627282930313233343536/** * Initializes table, using the size recorded in sizeCtl. * 使用sizeCtl中记录的大小初始化表。 */private final Node<K,V>[] initTable() { Node<K,V>[] tab; int sc; //只要表为空，就一直循环 while ((tab = table) == null || tab.length == 0) { //如果sizeCtl小于0， if ((sc = sizeCtl) < 0) //用了yield方法后，该线程就会把CPU时间让掉，让其他或者自己的线程执行（也就是谁先抢到谁执行） Thread.yield(); // lost in ...
JAVA并发容器源码分析【二】ConcurrentHashMap分析之计数
计数操作，并发情况下好复杂。JDK8ConcurrentHashMap在插入和删除的情况下都会调用addCount方法：
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172/** * Adds to count, and if table is too small and not already * resizing, initiates transfer. If already resizing, helps * perform transfer if work is available. Rechecks occupancy * after a transfer to see if another resize is already needed * because resizings are lagging additions. * &l ...
