Java集合学习笔记

Posted 2020-09-04 无知者云

 

在Java中，我们经常听到Collections框架、Collection类以及Collections类。这三者名字相似，但是从概念上讲却是不同的。Collections框架泛指Java中用于存储和操作集合的类库总和，其中包括了List、Set和Map等。但是在具体实现上，由于Map中装的是Key-Value的键值对元素，其接口形式和其他（比如List）接口不一样，因此在Java中Map被区分对待了。总的来看，位于Java Collections框架中最顶层的接口有两个，Collection类和Map类，此时整个Java Collections框架的类层级如下：

 

 

 

 

Java中存在不少泛化的方法能够直接对Collection接口进行操作，而不用关心具体的实现类是什么，比如在查找一个集合中的最大值元素的时候——即实现一个max()方法，此时我们并不需要知道这个集合具体的实现类是ArrayList还是HashSet，而只需要知道这是一个Collection集合即可。另外，这个max()方法对于所有具体实现类来说其实原理是一样的，因此没有必要让每一个集合实现类自己再去实现一份。基于此，Java引入了一个Collections工具类来辅助实现这些方法，比如操作集合和创建集合等。由于名字和Collection相似，Collections通常给程序员们带来误解，这一点需要注意。当然，Java 8中引入了“默认方法”(Default Method)的技术，使得理论上诸如max()这样的方法可以直接实现在Collection接口上。 

 

集合类的选用

在平时开发中，程序员们使用最多了莫过于ArrayList、HashSet和HashMap了。在多数情况下，这三个实现类已经能够满足我们的大部分需求，但是如果稍加分析我们可能会发现另外一些集合实现类能更好的满足我们的需要。比如，当你需要一个有顺序的Set时，可以考虑选用LinkedHashSet而不是HashSet。关于集合类是选用，可以参考下图：

 

 

 

 

equals()和hashCode()方法

工作过一段时间的Java程序员基本上都知道equals()和hashCode()之间存在着以下契约关系：

1. 如果两个对象通过equals()方法判断出是相等的，那么他们hashCode也应该相等；
2. 如果两个对象通过equals()方法判断不等，那么他们hashCode可以相等，也可以不等。

如果没有实现以上两条（特别是第1条），在使用Java某些集合时（特别是HashSet和HashMap），你将得不到想要的结果，甚至造成严重的内存泄漏问题。要搞明白里面的原由，我们还得从HashMap的内部实现开始说起。

 

HashMap在存储键值对（Key-Value Pair）时，首先调用Key对象的hashCode()方法得到一个数字，这个数字对应了该键值对在HashMap中的存放位置，每个位置上不仅存放了Value，还存放了Key，即键值对（如下图所示）。我们将存放键值对的位置叫做一个Bucket（中文名为“桶”，即用来装东西的容器，很形象哈），Bucket中维护了一个LinkedList(下图中的Entries)，该LinkedList用于存放实际的键值对本身。因此，要通过Key来获取到相应的Value，Java只需要再次调用Key的hashCode()方法得到该键值对在HashMap中的位置，便可以准确快速地获取到Key对应的Value。因此，即便用于存放的Key和用于获取的Key是相等的，如果他们的hashCode不等，那么在获取时便得不到先前存放的准确位置，进而得不到正确的结果。另外，如果Key对象的类没有实现equals()方法，那么默认情况下Java将使用对象的引用地址来判断两个对象的相等性， 而之后我们又很难再次创建出一个和先前引用地址相同的对象，因此便可能出现永远也获取不到Value的情况，从而导致内存泄漏。进而我们得到另一个结论：如果一个类的对象将被用于HashMap的Key或者被直接放入Set集合中，那么这个类应该实现equals()方法和hashCode()方法。

 

 

 

注意到上图中的152号Bucket了吗？我们发现同时有John Smith和Sandra Dee两个Key都指向了这个相同的Bucket，即这两个对象的hashCode相等。这便是equals()和hashCode()契约关系的第2点。Java采用了LinkedList来存放所有Key的hashCode相等的键值对。此时在LinkedList中，前一个键值对维护了一个指针指向了下一个键值对。当之后通过John Smith来获取Value时，Java首先发现其对应的Bucket中存在着两个键值对，然后Java分别将各个键值对中Key对象与所传来的Key对象相比，如果相等则返回该键值对所对应的Value。由此，我们也知道HashMap中为什么需要同时存Key和Value而不是只存Value的原因；同时也知道了契约第2点的来由。事实上，我们可以让一个类的所有对象都返回相同的hashCode，只是此时如果该类的对象作为Key时，所有的键值对都将存放都相同的Bucket位置，每次在获取的时候都需要做多次的比较，因此会影响HashMap的获取速度。

 

线程安全性

通常来说，在Java中可以通过两种方式来实现线程安全，一种是通过Java自带的并发管控手段（比如使用syncronized关键字），另一中是通过创建不可变（Immutable）对象。

 

在很早的时候，Java里面有Vector和HashTable两个集合对象，他们通过使用syncronized关键字实现了线程安全，但是同时也暴露出了很大的性能问题。因此现在基本上没有人使用了。为了解决Vector和HashTable的性能问题，Java从1.2引入的Collections框架采用了线程不安全的类，比如ArrayList和HashMap都是线程不安全的。当然，为了性能而牺牲了线程安全性也是不可取的，因此Java通过Fail-Fast的Iterator来避免多个线程同时操作集合所带的线程冲突问题。比如，当一个线程正在遍历一个集合而另一个线程正在修改该集合时，前者将抛出ConcurrentModificationException。这当然也不是万全的办法。

 

另一方面，Java其实也提供了线程安全的封装类（Wrapper）来实现集合的线程安全性，我们可以通过：

Collections.synchronizedXXX(collection)

来创建线程安全的集合，这里的XXX可以是Collection、List、Map和Set等。对于一个常规的colleciton对象，调用(synchronizedXXX)方法将得到封装后的线程安全性。

 

集合封装类同样采用了syncronized关键字来达到线程安全性，并且是在整个集合类上上锁，这样也会带来严重的性能问题。为了解决这样的问题，从Java 5开始引入了并发集合(Concurrent Collections)，他们要么采用Immutable集合，要么采用更加精细的锁控制来达到线程安全的目的，同时又能保证很高的性能。

 

并发集合主要包含三类，一是Copy-On-Write集合，二是Compare-And-Swap集合，三是采用特殊锁的并发集合。Copy-On-Write集合底层维护的是一个不变的（Immutable）的数组，通过在写（Write）入集合时重新复制（Copy）一份新的集合来达到线程安全，进而得名Copy-On-Write。Coppy-On-Write集合包括有CopyOnWriteArrayList和CopyOnWriteArraySet等。Compare-And-Swap集合在进行更新的时候，首先维护一个本地拷贝，当执行更新时，比较本地拷贝与原值，如果值相等，则证明在这段时间内还没有其他线程修改原值，此时立即更新；如果不相等，则重新拷贝原值，再计算，再更新，这样也到了线程安全的目的。Compare-And-Swap集合包括ConcurrentLinkedQueue和ConcurrentSkipListMap等。第三类是使用特殊锁的集合，这种集合类并不在整个集合类上上锁，而是通过在Bucket级别上上锁，从而达到了对并发的更精细的控制，减少了线程的等待时间，从而提高了并发性能。

 

除了提供并发控制机制外，Java还提供了不可修改的（unmodifiable）集合来保证线程安全性，可以通过：

Collections.unmodifiableXXX(collection)

来创建不同unmodifiable集合。这样的集合其实也是一个封装类，对于传入的正常集合collection，通过对add()等方法抛出UnsupportedOperationException异常来达到不可修改的目的。但是，这样的集合其实并不达到不可修改目的，因为被其包装的collection本身依然是可以修改的。

 

为了实现更好的集合不变性，Guava类库提供了很多Immutable的集合，这些集合是真正不变的。