[TOC]
同步容器类
早期的同步容器类包括Vector（ArrayList的同步版本），Hashtable（早期HashMap的同步版本）。另外还有使用同步封装器Collections.synchronizedXXX等工厂方法创建的同步类。这些同步类实现线程安全的方式是将容器的状态封装起来，把读写容器状态的方法使用synchronized保护起来从而达到同步的作用。
同步容器的问题
同步容器类本身是线程安全的，但是在其之上的复合操作，可能就需要进行额外的加锁操作才能保证线程安全性。如：
- 迭代（反复访问元素，直到遍历容器中的所有元素）
- 跳转（根据指定顺序找到当前元素的下一个元素）
- 条件运算（不存在就添加之类的操作）
在并发情况下，容器的复合操作可能是并发不安全的，这个时候就需要对容器进行“客户端”加锁，所谓的客户端加锁就是我们在使用容器的时候，主动对其某些操作进行显式地加锁操作，对于容器类本身来说，我们写的代码就是客户端代码。
进行客户端加锁需要注意的是，必须了解容器内部的加锁机制，比如容器内是使用什么对象进行加锁的，因为若想要正确同步，必须要让并发线程竞争同一个锁对象，否则加锁就是无意义的。这一点同步需要注意，并非简单加个synchronized关键字就能保证同步了。
另外一点是客户端加锁带来的性能损失，如对容器的迭代进行同步加锁，那么当一个线程对其进行迭代操作时，其他线程不能访问和修改容器，这就牺牲了可伸缩性。
如：
synchronized(syncHashMap){
Iterator<K> iter = synchHashMap.keySet().iterator();
while(iter.hasNext())
//...
}
另外，如果使用for-each循环，实际上内部也是使用的iterator进行迭代的，也需要客户端加锁来保证线程安全。
可伸缩性
可伸缩性，简单来说，是以更大的规模来做你现在所做的事。伸展一个Web应用的规模在于让更多的人使用你的程序。如果你没法找出方法在伸展规模的同时提高性能，没关系。而且只要你可以伸展规模来处理更大数量的用户，那么有几个单点故障（single point of failure）也没关系。
Royans解释说如今我们在面对规模伸展的时候有两个选择：
- 纵向的可伸缩性——在同一个逻辑单元内增加资源来提高处理能力。这样的例子包括在现有服务器上增加CPU，或者在现有的RAID/SAN存储中增加硬盘来提高存储量。
- 横向的可伸缩性——增加更多逻辑单元的资源，并令它们像是一个单元一样工作。大多数集群方案、分布式文件系统、负载平衡都是在帮助你提高横向的可伸缩性。
迭代和fail-fast机制
如果在迭代过程中，别的线程修改了集合，迭代器就会失效，抛出ConcurrentModificationException异常。
这种fail-fast的迭代器并不是一种完备的处理机制，而只是“善意地”捕捉并发错误，并不能解决并发带来的问题。
如果不希望在迭代期间对容器加锁，可以使用迭代克隆容器的方法，在容器的副本上进行迭代。
虽然加锁可以防止在迭代期间抛出抛出ConcurrentModificationException异常，但是必须要记住在所有对共享容器进行迭代的地方都需要加锁，一些隐式的迭代尤其需要注意。然后print语句中打印容器，会隐式调用tostring方法，可能会对容器进行迭代处理。
并发容器
Java5提供了多种并发容器来改进同步容器的性能。同步容器将所有对容器状态的访问操作都串行化，以换取线程安全性。这种方式是代价是严重降低并发性，当大量线程访问容器时，吞吐量严重降低。
并发容器时针对并发访问而设计的。Java5提供了ConcurrentHashMap来替代基本散列的同步map，以及CopyOnWriteArrayList用来在以遍历操作为主的情况下代替同步的list（对于经常修改的数组列表，同步的ArrayList可以胜过CopyOnWriteList）。在并发容器中增加了一些曾经需要客户端加锁的复合操作的并发安全版本，如若没有就添加，替换及有条件的删除等。
Java5新增了两种新的容器类型：Queue和BlockingQueue。Queue上的操作不会阻塞，如果队列时空，返回就是空。BlockingQueue扩展了Queue，增加了可阻塞的插入和获取操作。
ConcurrentHashMap
ConcurrentHashMap在数据结构的特性上和HashMap是一样的，不同的是它所使用的加锁机制。在Java8之前，CHM使用的是分段锁的技术，所谓的分段锁是将整个HashMap分成了许多个Segment，每个Segment存储HashMap的一部分Bucket，Bucket存储具体的数据节点，这里不详细阐述底层数据结构的实现，主要看分段锁。每个Segment维护一个锁对象，所以在并发访问的时候，访问的数据能够因为锁的错开而减少锁竞争的开销，从而提高并发的性能。
在Java8中，Doug Lea重写了加锁机制的实现，使用了CAS算法实现无锁化的并发HashMap。
CHM和其他的并发容器一起增强了同步容器类：它们提供的迭代器不会抛出ConcurrentModificationException，因此不需要在迭代过程中对容器加锁。CHM返回的迭代器具有弱一致性，而非同步容器的fail-fast机制。弱一致性容器能够容忍并发的修改。但弱一致性的size和IsEmpty方法的返回值只是近似值，不过在并发环境下，它们的用处很小，因为一直在变化。
CHM没有实现对Map加锁以提供独占访问。也正因为如此，我们无法使用客户端加锁来创建新的原子操作。但是一般的条件运算，内部已经提供了线程安全的方法。
CopyOnWriteArrayList
CopyOnWriteArrayLIst用于替代同步的List，在某些情况下能提供更好的性能，且在迭代期间不需要进行加锁。（CopyOnWriteArraySet用来替代同步Set）。
CopyOnWrite容器的线程安全性在于，只要正确地发布一个事实不可变的对象，那么在访问该对象时就不再需要进一步的同步。在每次修改时，都会创建并重新发布一个新的容器副本，以此来实现可变性。CopyOnWrite容器的迭代器保留一个指向底层基础数组的引用，这个数组当前位于迭代器的起始位置，由于它不会被修改，所以在对其进行同步时只需保证数组内容的可见性即可。
CopyOnWriteArrayList使用了一种叫写时复制的方法，当有新元素添加到CopyOnWriteArrayList时，先从原有的数组中拷贝一份出来，然后在新的数组做写操作，写完之后，再将原来的数组引用指向到新数组。每次修改容器是都会复制底层数组，这需要一定的开销，特别是当数组很大时。
CopyOnWriteArrayList的整个add操作都是在锁的保护下进行的。
这样做是为了避免在多线程并发add的时候，复制出多个副本出来,把数据搞乱了，导致最终的数组数据不是我们期望的。
由于所有的写操作都是在新数组进行的，这个时候如果有线程并发的写，则通过锁来控制，如果有线程并发的读，则分几种情况：
- 如果写操作未完成，那么直接读取原数组的数据；
- 如果写操作完成，但是引用还未指向新数组，那么也是读取原数组数据；
- 如果写操作完成，并且引用已经指向了新的数组，那么直接从新数组中读取数据。
即读操作是无锁的。
缺点：
由于写操作的时候，需要拷贝数组，会消耗内存，如果原数组的内容比较多的情况下，可能导致young gc或者full gc
不能用于实时读的场景，像拷贝数组、新增元素都需要时间，所以调用一个set操作后，读取到数据可能还是旧的,虽然CopyOnWriteArrayList 能做到最终一致性,但是还是没法满足实时性要求；
CopyOnWriteArrayList 合适读多写少的场景，不过这类慎用。
