Synchronized vs Concurrent Collections（并发集合VS同步集合）

Posted 2022-11-21 面具人生lql

Synchronized vs Concurrent Collections

注：文中ConcurrentHashMap指JDK1.5-1.7版本，在1.8中发生了很大的变化

不管是同步集合还是并发集合他们都支持线程安全，他们之间主要的区别体现在性能和可扩展性，还有他们如何实现的线程安全。同步HashMap, Hashtable, HashSet, Vector, ArrayList 相比他们并发的实现（比如：ConcurrentHashMap, CopyOnWriteArrayList, CopyOnWriteHashSet）会慢得多。造成如此慢的主要原因是锁， 同步集合会把整个Map或List锁起来，而并发集合不会。并发集合实现线程安全是通过使用先进的和成熟的技术像锁剥离。比如ConcurrentHashMap 会把整个Map 划分成几个片段，只对相关的几个片段上锁，同时允许多线程访问其他未上锁的片段。

同样的，CopyOnWriteArrayList 允许多个线程以非同步的方式读，当有线程写的时候它会将整个List复制一个副本给它。

如果在读多写少这种对并发集合有利的条件下使用并发集合，这会比使用同步集合更具有可伸缩性。

顺便说一下，集合类是Java API的核心，所以我觉得明智而审慎地使用它们是一门艺术。这是我的个人经验,我通过使用ArrayList替换遗留代码里使用的Vector来提高性能。JDK 1.5引入一些很好的并发集合能高效地开发高容量,低延迟的Java应用程序。

Synchronized Collections vs Concurrent Collections in Java

同步集合类，Hashtable 和 Vector 还有同步集合包装类，Collections.synchronizedMap()和Collections.synchronizedList() 提供了一个基本的有条件的线程安全的Map和List的实现。

所以Hashtable和ConcurrentHashMap的区别是什么,他们都可以在多线程环境中使用，但一旦Hashtable 的大小变得相当大的时候，其性能会降低,因为迭代的时候会被长时间锁定。

然而有一些因素导致他们不适合在高并发应用程序中使用，最主要的原因是在他们的‘集合范围’的锁是程序可伸缩性的一个阻碍。它往往成为必须在相当长一段时间内对集合加锁以防止在迭代期间出现ConcurrentModificationException。

ConcurrentHashMap和CopyOnWriteArrayList不一定在所有地方都是有用的，一般情况下你只需要使用HashMap或ArrayList。

因为ConcurrentHashMap 引入了分片的概念，所以无论集合有多大，她都只对特定的片段进行加锁以保障线程安全，其他的读线程仍然可以访问map而不用等待正在访问的线程遍历结束。

你也可以看看Cay S. Horstmann的 Core Java Volume 1 - Fundamentals去更多地了解并发集合是如何工作的。我在这本书中找到了关于Java API和编程语言的各种事情的解释，非常丰富和容易消化。这是我强烈推荐这本书的主要原因。

原文地址

可伸缩性

可伸缩性指的是一个应用程序在工作负载和可用处理资源增加时其吞吐量的表现情况。一个可伸缩的程序能够通过使用更多的处理器、内存或者I/O带宽来相应地处理更大的工作负载。锁住某个共享的资源以获得独占式的访问这种做法会形成可伸缩性瓶颈――它使其他线程不能访问那个资源，即使有空闲的处理器可以调用那些线程也无济于事。为了取得可伸缩性，我们必须消除或者减少我们对独占式资源锁的依赖。

PS：原文段落结构挺乱，翻译得也挺乱，见谅！