Java集合学习笔记
![](https://images2015.cnblogs.com/blog/341412/201703/341412-20170312124208920-515063510.png)
![](https://images2015.cnblogs.com/blog/341412/201703/341412-20170312130217107-1972661698.png)
- 如果两个对象通过equals()方法判断出是相等的,那么他们hashCode也应该相等;
- 如果两个对象通过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的集合,这些集合是真正不变的。