[JAVA学习笔记-92]concurrentLinkedQueue的特性

1、应用场景
按照适用的并发强度从低到高排列如下：
LinkedList/ArrayList   非线程安全，不能用于并发场景（List的方法支持栈和队列的操作，因此可以用List封装成stack和queue）
Collections.synchronizedList   使用wrapper class封装，每个方法都用synchronized(mutex:Object)做了同步
LinkedBlockingQueue  采用了锁分离的设计，避免了读/写操作冲突，且自动负载均衡，可以有界。BlockingQueue在生产-消费模式下首选【Iterator安全，不保证数据一致性】
ConcurrentLinkedQueue  适用于高并发读写操作，理论上有最高的吞吐量，无界，不保证数据访问实时一致性，Iterator不抛出并发修改异常，采用CAS机制实现无锁访问。

综上：
在并发的场景下，如果并发强度较小，性能要求不苛刻，且锁可控的场景下，可使用Collections.synchronizedList，既保证了数据一致又保证了线程安全，性能够用；
在大部分高并发场景下，建议使用 LinkedBlockingQueue ，性能与 ConcurrentLinkedQueue 接近，且能保证数据一致性；
ConcurrentLinkedQueue 适用于超高并发的场景，但是需要针对数据不一致采取一些措施。
2、特点
2.1 访问操作采用了无锁设计
2.2 Iterator的弱一致性，即不保证Iteartor访问数据的实时一致性（与current组的成员与COW成员类似）
2.3 并发poll
2.4 并发add
2.5 poll/add并发


3、注意事项
3.1 size操作不是一个固定时长的操作（not a constant-time operation）
因为size需要遍历整个queue，如果此时queue正在被修改，size可能返回不准确的数值（仍然是无法保证数据一致性），就像concurrentHashMap一样，
要获取size，需要取得所有的bucket的锁，这是一个非常耗时的操作。因此如果需要保证数据一致性，频繁获取集合对象的size，最好不使用concurrent
族的成员。

3.2 批量操作（bulk operations like addAll,removeAll,equals）无法保证原子性，因为不保证实时性，且没有使用独占锁的设计。
例如，在执行addAll的同时，有另外一个线程通过Iterator在遍历，则遍历的线程可能只看到一部分新增的数据。

3.3 ConcurrentLinkedQueue 没有实现BlockingQueue接口
当队列为空时，take方法返回null，此时consumer会需要处理这个情况，consumer会循环调用take来保证及时获取数据，此为busy waiting，会持续消耗CPU资源。



4、与 LinkedBlockingQueue 的对比
LinkedBlockingQueue 采用了锁分离的设计，put、get锁分离，保证两种操作的并发，但同一种操作，然后是锁控制的。并且当队列为空/满时，某种操作
会被挂起。

4.1 并发性能
4.1.1 高并发put操作
可支持高并发场景下，多线程无锁put操作
4.1.2 高并发的put/poll操作
多线程场景，同时put，遍历，以及poll，均可无锁操作。但不保证遍历的实时一致性。

4.2 数据的实时一致性
两者的Iterator都不不保证数据一致性，Iterator遍历的是Iterator创建时已存在的节点，创建后的修改不保证能反应出来。
参考 LinkedBlockingQueue 的java doc关于Iterator的解释：
The returned iterator is a "weakly consistent" iterator that will never throw ConcurrentModificationException, and guarantees to traverse elements as they existed upon construction of the iterator, and may (but is not guaranteed to) reflect any modifications subsequent to construction.

4.3 遍历操作(Iterator的遍历操作的差异)
目前看来，没有差异

4.4 size操作
LinkedBlockingQueue 的size是在内部用一个AtomicInteger保存，执行size操作直接获取此原子量的当前值，时间复杂度O(1)。
ConcurrentLinkedQueue 的size操作需要遍历（traverse the queue），因此比较耗时，时间复杂度至少为O(n),建议使用isEmpty()。
The java doc says the size() method is typically not very useful in concurrent applications.