Java深度解析之线程控制与垃圾回收

现在的位置: 首页 > 程序设计> 正文

上篇下篇

Java深度解析之线程控制与垃圾回收

2011年08月02日 ⁄ 程序设计 ⁄ 暂无评论 ⁄ 被围观 4,761+

本系列的文章转载自infoq专栏合集《Java深度历险》，10篇文章分别由浅到深描述了Java的多个细节，具体包括
1. Java 字节代码的操纵 2. Java类的加载、链接和初始化 3. Java线程:基本概念、可见性与同步
4. Java垃圾回收机制与引用类型 5. Java泛型 6. Java注解 7. Java反射与动态代理
8. Java I/O 9. Java安全 10. Java对象序列化与RMI，
相信通过十个主题的学习，读者能对Java的这几个方面有较深入的理解。enjoy it！

Java线程：基本概念、可见性与同步

开发高性能并发应用不是一件容易的事情。这类应用的例子包括高性能Web服务器、游戏服务器和搜索引擎爬虫等。这样的应用可能需要同时处理成千上万个请求。对于这样的应用，一般采用多线程或事件驱动的架构。对于Java来说，在语言内部提供了线程的支持。但是Java的多线程应用开发会遇到很多问题。首先是很难编写正确，其次是很难测试是否正确，最后是出现问题时很难调试。一个多线程应用可能运行了好几天都没问题，然后突然就出现了问题，之后却又无法再次重现出来。如果在正确性之外，还需要考虑应用的吞吐量和性能优化的话，就会更加复杂。本文主要介绍Java中的线程的基本概念、可见性和线程同步相关的内容。

Java线程基本概念

在操作系统中两个比较容易混淆的概念是进程（process）和线程（thread）。操作系统中的进程是资源的组织单位。进程有一个包含了程序内容和数据的地址空间，以及其它的资源，包括打开的文件、子进程和信号处理器等。不同进程的地址空间是互相隔离的。而线程表示的是程序的执行流程，是CPU调度的基本单位。线程有自己的程序计数器、寄存器、栈和帧等。引入线程的动机在于操作系统中阻塞式I/O的存在。当一个线程所执行的I/O被阻塞的时候，同一进程中的其它线程可以使用CPU来进行计算。这样的话，就提高了应用的执行效率。线程的概念在主流的操作系统和编程语言中都得到了支持。

一部分的Java程序是单线程的。程序的机器指令按照程序中给定的顺序依次执行。Java语言提供了java.lang.Thread类来为线程提供抽象。有两种方式创建一个新的线程：一种是继承java.lang.Thread类并覆写其中的run()方法，另外一种则是在创建java.lang.Thread类的对象的时候，在构造函数中提供一个实现了java.lang.Runnable接口的类的对象。在得到了java.lang.Thread类的对象之后，通过调用其start()方法就可以启动这个线程的执行。

一个线程被创建成功并启动之后，可以处在不同的状态中。这个线程可能正在占用CPU时间运行；也可能处在就绪状态，等待被调度执行；还可能阻塞在某个资源或是事件上。多个就绪状态的线程会竞争CPU时间以获得被执行的机会，而CPU则采用某种算法来调度线程的执行。不同线程的运行顺序是不确定的，多线程程序中的逻辑不能依赖于CPU的调度算法。

可见性

可见性（visibility）的问题是Java多线程应用中的错误的根源。在一个单线程程序中，如果首先改变一个变量的值，再读取该变量的值的时候，所读取到的值就是上次写操作写入的值。也就是说前面操作的结果对后面的操作是肯定可见的。但是在多线程程序中，如果不使用一定的同步机制，就不能保证一个线程所写入的值对另外一个线程是可见的。造成这种情况的原因可能有下面几个：

CPU 内部的缓存：现在的CPU一般都拥有层次结构的几级缓存。CPU直接操作的是缓存中的数据，并在需要的时候把缓存中的数据与主存进行同步。因此在某些时刻，缓存中的数据与主存内的数据可能是不一致的。某个线程所执行的写入操作的新值可能当前还保存在CPU的缓存中，还没有被写回到主存中。这个时候，另外一个线程的读取操作读取的就还是主存中的旧值。
CPU的指令执行顺序：在某些时候，CPU可能改变指令的执行顺序。这有可能导致一个线程过早的看到另外一个线程的写入操作完成之后的新值。
编译器代码重排：出于性能优化的目的，编译器可能在编译的时候对生成的目标代码进行重新排列。

现实的情况是：不同的CPU可能采用不同的架构，而这样的问题在多核处理器和多处理器系统中变得尤其复杂。而Java的目标是要实现“编写一次，到处运行”，因此就有必要对Java程序访问和操作主存的方式做出规范，以保证同样的程序在不同的CPU架构上的运行结果是一致的。Java内存模型（Java Memory Model）就是为了这个目的而引入的。JSR 133则进一步修正了之前的内存模型中存在的问题。总得来说，Java内存模型描述了程序中共享变量的关系以及在主存中写入和读取这些变量值的底层细节。

Java内存模型定义了Java语言中的synchronized、volatile和final等关键词对主存中变量读写操作的意义。Java开发人员使用这些关键词来描述程序所期望的行为，而编译器和JVM负责保证生成的代码在运行时刻的行为符合内存模型的描述。比如对声明为volatile的变量来说，在读取之前，JVM会确保CPU中缓存的值首先会失效，重新从主存中进行读取；而写入之后，新的值会被马上写入到主存中。而synchronized和volatile关键词也会对编译器优化时候的代码重排带来额外的限制。比如编译器不能把 synchronized块中的代码移出来。对volatile变量的读写操作是不能与其它读写操作一块重新排列的。

Java 内存模型中一个重要的概念是定义了“在之前发生（happens-before）”的顺序。如果一个动作按照“在之前发生”的顺序发生在另外一个动作之前，那么前一个动作的结果在多线程的情况下对于后一个动作就是肯定可见的。最常见的“在之前发生”的顺序包括：对一个对象上的监视器的解锁操作肯定发生在下一个对同一个监视器的加锁操作之前；对声明为volatile的变量的写操作肯定发生在后续的读操作之前。有了“在之前发生”顺序，多线程程序在运行时刻的行为在关键部分上就是可预测的了。编译器和JVM会确保“在之前发生”顺序可以得到保证。比如下面的一个简单的方法：

1
2
3

public void increase() {
    this.count++;
}

public void increase() {
    this.count++;
}

这是一个常见的计数器递增方法，this.count++实际是this.count = this.count + 1，由一个对变量this.count的读取操作和写入操作组成。如果在多线程情况下，两个线程执行这两个操作的顺序是不可预期的。如果 this.count的初始值是1，两个线程可能都读到了为1的值，然后先后把this.count的值设为2，从而产生错误。错误的原因在于其中一个线程对this.count的写入操作对另外一个线程是不可见的，另外一个线程不知道this.count的值已经发生了变化。如果在increase() 方法声明中加上synchronized关键词，那就在两个线程的操作之间强制定义了一个“在之前发生”顺序。一个线程需要首先获得当前对象上的锁才能执行，在它拥有锁的这段时间完成对this.count的写入操作。而另一个线程只有在当前线程释放了锁之后才能执行。这样的话，就保证了两个线程对 increase()方法的调用只能依次完成，保证了线程之间操作上的可见性。

如果一个变量的值可能被多个线程读取，又能被最少一个线程锁写入，同时这些读写操作之间并没有定义好的“在之前发生”的顺序的话，那么在这个变量上就存在数据竞争（data race）。数据竞争的存在是Java多线程应用中要解决的首要问题。解决的办法就是通过synchronized和volatile关键词来定义好“在之前发生”顺序。

Java中的锁

当数据竞争存在的时候，最简单的解决办法就是加锁。锁机制限制在同一时间只允许一个线程访问产生竞争的数据的临界区。Java语言中的 synchronized关键字可以为一个代码块或是方法进行加锁。任何Java对象都有一个自己的监视器，可以进行加锁和解锁操作。当受到 synchronized关键字保护的代码块或方法被执行的时候，就说明当前线程已经成功的获取了对象的监视器上的锁。当代码块或是方法正常执行完成或是发生异常退出的时候，当前线程所获取的锁会被自动释放。一个线程可以在一个Java对象上加多次锁。同时JVM保证了在获取锁之前和释放锁之后，变量的值是与主存中的内容同步的。

Java线程的同步

在有些情况下，仅依靠线程之间对数据的互斥访问是不够的。有些线程之间存在协作关系，需要按照一定的协议来协同完成某项任务，比如典型的生产者-消费者模式。这种情况下就需要用到Java提供的线程之间的等待-通知机制。当线程所要求的条件不满足时，就进入等待状态；而另外的线程则负责在合适的时机发出通知来唤醒等待中的线程。Java中的java.lang.Object类中的wait/notify/notifyAll方法组就是完成线程之间的同步的。

在某个Java对象上面调用wait方法的时候，首先要检查当前线程是否获取到了这个对象上的锁。如果没有的话，就会直接抛出java.lang.IllegalMonitorStateException异常。如果有锁的话，就把当前线程添加到对象的等待集合中，并释放其所拥有的锁。当前线程被阻塞，无法继续执行，直到被从对象的等待集合中移除。引起某个线程从对象的等待集合中移除的原因有很多：对象上的notify方法被调用时，该线程被选中；对象上的notifyAll方法被调用；线程被中断；对于有超时限制的wait操作，当超过时间限制时；JVM内部实现在非正常情况下的操作。

从上面的说明中，可以得到几条结论：wait/notify/notifyAll操作需要放在synchronized代码块或方法中，这样才能保证在执行 wait/notify/notifyAll的时候，当前线程已经获得了所需要的锁。当对于某个对象的等待集合中的线程数目没有把握的时候，最好使用 notifyAll而不是notify。notifyAll虽然会导致线程在没有必要的情况下被唤醒而产生性能影响，但是在使用上更加简单一些。由于线程可能在非正常情况下被意外唤醒，一般需要把wait操作放在一个循环中，并检查所要求的逻辑条件是否满足。典型的使用模式如下所示：

private Object lock = new Object();
synchronized (lock) {
    while (/* 逻辑条件不满足的时候 */) {
       try {
           lock.wait();
       } catch (InterruptedException e) {}
    }
    //处理逻辑
}

private Object lock = new Object();
synchronized (lock) {
    while (/* 逻辑条件不满足的时候 */) {
       try {
           lock.wait();
       } catch (InterruptedException e) {}
    }
    //处理逻辑
}

上述代码中使用了一个私有对象lock来作为加锁的对象，其好处是可以避免其它代码错误的使用这个对象。

中断线程

通过一个线程对象的interrupt()方法可以向该线程发出一个中断请求。中断请求是一种线程之间的协作方式。当线程A通过调用线程B的interrupt()方法来发出中断请求的时候，线程A 是在请求线程B的注意。线程B应该在方便的时候来处理这个中断请求，当然这不是必须的。当中断发生的时候，线程对象中会有一个标记来记录当前的中断状态。通过isInterrupted()方法可以判断是否有中断请求发生。如果当中断请求发生的时候，线程正处于阻塞状态，那么这个中断请求会导致该线程退出阻塞状态。可能造成线程处于阻塞状态的情况有：当线程通过调用wait()方法进入一个对象的等待集合中，或是通过sleep()方法来暂时休眠，或是通过join()方法来等待另外一个线程完成的时候。在线程阻塞的情况下，当中断发生的时候，会抛出java.lang.InterruptedException，代码会进入相应的异常处理逻辑之中。实际上在调用wait/sleep/join方法的时候，是必须捕获这个异常的。中断一个正在某个对象的等待集合中的线程，会使得这个线程从等待集合中被移除，使得它可以在再次获得锁之后，继续执行java.lang.InterruptedException异常的处理逻辑。

通过中断线程可以实现可取消的任务。在任务的执行过程中可以定期检查当前线程的中断标记，如果线程收到了中断请求，那么就可以终止这个任务的执行。当遇到 java.lang.InterruptedException的异常，不要捕获了之后不做任何处理。如果不想在这个层次上处理这个异常，就把异常重新抛出。当一个在阻塞状态的线程被中断并且抛出java.lang.InterruptedException异常的时候，其对象中的中断状态标记会被清空。如果捕获了java.lang.InterruptedException异常但是又不能重新抛出的话，需要通过再次调用interrupt()方法来重新设置这个标记。
参考资料

现代操作系统?
Java语言规范（第三版）第17章：线程与锁
Java内存模型FAQ
Fixing the Java Memory Model, Part 1 & Part 2

Java垃圾回收机制与引用类型

Java语言的一个重要特性是引入了自动的内存管理机制，使得开发人员不用自己来管理应用中的内存。C/C++开发人员需要通过malloc/free 和new/delete等函数来显式的分配和释放内存。这对开发人员提出了比较高的要求，容易造成内存访问错误和内存泄露等问题。一个常见的问题是会产生“悬挂引用（dangling references）”，即一个对象引用所指向的内存区块已经被错误的回收并重新分配给新的对象了，程序如果继续使用这个引用的话会造成不可预期的结果。开发人员有可能忘记显式的调用释放内存的函数而造成内存泄露。而自动的内存管理则是把管理内存的任务交给编程语言的运行环境来完成。开发人员并不需要关心内存的分配和回收的底层细节。Java平台通过垃圾回收器来进行自动的内存管理。

Java垃圾回收机制
Java的垃圾回收器要负责完成3件任务：分配内存、确保被引用的对象的内存不被错误回收以及回收不再被引用的对象的内存空间。垃圾回收是一个复杂而且耗时的操作。如果JVM花费过多的时间在垃圾回收上，则势必会影响应用的运行性能。一般情况下，当垃圾回收器在进行回收操作的时候，整个应用的执行是被暂时中止（stop-the-world）的。这是因为垃圾回收器需要更新应用中所有对象引用的实际内存地址。不同的硬件平台所能支持的垃圾回收方式也不同。比如在多CPU的平台上，就可以通过并行的方式来回收垃圾。而单CPU平台则只能串行进行。不同的应用所期望的垃圾回收方式也会有所不同。服务器端应用可能希望在应用的整个运行时间中，花在垃圾回收上的时间总数越小越好。而对于与用户交互的应用来说，则可能希望所垃圾回收所带来的应用停顿的时间间隔越小越好。对于这种情况，JVM中提供了多种垃圾回收方法以及对应的性能调优参数，应用可以根据需要来进行定制。

Java 垃圾回收机制最基本的做法是分代回收。内存中的区域被划分成不同的世代，对象根据其存活的时间被保存在对应世代的区域中。一般的实现是划分成3个世代：年轻、年老和永久。内存的分配是发生在年轻世代中的。当一个对象存活时间足够长的时候，它就会被复制到年老世代中。对于不同的世代可以使用不同的垃圾回收算法。进行世代划分的出发点是对应用中对象存活时间进行研究之后得出的统计规律。一般来说，一个应用中的大部分对象的存活时间都很短。比如局部变量的存活时间就只在方法的执行过程中。基于这一点，对于年轻世代的垃圾回收算法就可以很有针对性。

年轻世代的内存区域被进一步划分成伊甸园（Eden）和两个存活区（survivor space）。伊甸园是进行内存分配的地方，是一块连续的空闲内存区域。在上面进行内存分配速度非常快，因为不需要进行可用内存块的查找。两个存活区中始终有一个是空白的。在进行垃圾回收的时候，伊甸园和其中一个非空存活区中还存活的对象根据其存活时间被复制到当前空白的存活区或年老世代中。经过这一次的复制之后，之前非空的存活区中包含了当前还存活的对象，而伊甸园和另一个存活区中的内容已经不再需要了，只需要简单地把这两个区域清空即可。下一次垃圾回收的时候，这两个存活区的角色就发生了交换。一般来说，年轻世代区域较小，而且大部分对象都已经不再存活，因此在其中查找存活对象的效率较高。

而对于年老和永久世代的内存区域，则采用的是不同的回收算法，称为“标记-清除-压缩（Mark-Sweep-Compact）”。标记的过程是找出当前还存活的对象，并进行标记；清除则遍历整个内存区域，找出其中需要进行回收的区域；而压缩则把存活对象的内存移动到整个内存区域的一端，使得另一端是一块连续的空闲区域，方便进行内存分配和复制。

JDK 5中提供了4种不同的垃圾回收机制。最常用的是串行回收方式，即使用单个CPU回收年轻和年老世代的内存。在回收的过程中，应用程序被暂时中止。回收方式使用的是上面提到的最基本的分代回收。串行回收方式适合于一般的单CPU桌面平台。如果是多CPU的平台，则适合的是并行回收方式。这种方式在对年轻世代进行回收的时候，会使用多个CPU来并行处理，可以提升回收的性能。并发标记-清除回收方式适合于对应用的响应时间要求比较高的情况，即需要减少垃圾回收所带来的应用暂时中止的时间。这种做法的优点在于可以在应用运行的同时标记存活对象与回收垃圾，而只需要暂时中止应用比较短的时间。

通过JDK中提供的JConsole可以很容易的查看当前应用的内存使用情况。在JVM启动的时候添加参数 -verbose:gc 可以查看垃圾回收器的运行结果。

Java引用类型
如果一个内存中的对象没有任何引用的话，就说明这个对象已经不再被使用了，从而可以成为被垃圾回收的候选。不过由于垃圾回收器的运行时间不确定，可被垃圾回收的对象的实际被回收时间是不确定的。对于一个对象来说，只要有引用的存在，它就会一直存在于内存中。如果这样的对象越来越多，超出了JVM中的内存总数，JVM就会抛出OutOfMemory错误。虽然垃圾回收的具体运行是由JVM来控制的，但是开发人员仍然可以在一定程度上与垃圾回收器进行交互，其目的在于更好的帮助垃圾回收器管理好应用的内存。这种交互方式就是使用JDK 1.2引入的java.lang.ref包。

强引用
在一般的Java程序中，见到最多的就是强引用（strong reference）。如Date date = new Date()，date就是一个对象的强引用。对象的强引用可以在程序中到处传递。很多情况下，会同时有多个引用指向同一个对象。强引用的存在限制了对象在内存中的存活时间。假如对象A中包含了一个对象B的强引用，那么一般情况下，对象B的存活时间就不会短于对象A。如果对象A没有显式的把对象B的引用设为null的话，就只有当对象A被垃圾回收之后，对象B才不再有引用指向它，才可能获得被垃圾回收的机会。

除了强引用之外，java.lang.ref包中提供了对一个对象的不同的引用方式。JVM的垃圾回收器对于不同类型的引用有不同的处理方式。

软引用
软引用（soft reference）在强度上弱于强引用，通过类SoftReference来表示。它的作用是告诉垃圾回收器，程序中的哪些对象是不那么重要，当内存不足的时候是可以被暂时回收的。当JVM中的内存不足的时候，垃圾回收器会释放那些只被软引用所指向的对象。如果全部释放完这些对象之后，内存还不足，才会抛出OutOfMemory错误。软引用非常适合于创建缓存。当系统内存不足的时候，缓存中的内容是可以被释放的。比如考虑一个图像编辑器的程序。该程序会把图像文件的全部内容都读取到内存中，以方便进行处理。而用户也可以同时打开多个文件。当同时打开的文件过多的时候，就可能造成内存不足。如果使用软引用来指向图像文件内容的话，垃圾回收器就可以在必要的时候回收掉这些内存。

public class ImageData {
    private String path;
    private SoftReference<byte[]> dataRef;
    public ImageData(String path) {
        this.path = path;
        dataRef = new SoftReference<byte[]>(new byte[0]);
    }
    private byte[] readImage() {
        return new byte[1024 * 1024]; //省略了读取文件的操作
  }
    public byte[] getData() {
        byte[] dataArray = dataRef.get();
        if (dataArray == null || dataArray.length == 0) {
            dataArray = readImage();
            dataRef = new SoftReference<byte[]>(dataArray);
        }
        return dataArray;
    }
}

public class ImageData {
    private String path;
    private SoftReference<byte[]> dataRef;
    public ImageData(String path) {
        this.path = path;
        dataRef = new SoftReference<byte[]>(new byte[0]);
    }
    private byte[] readImage() {
        return new byte[1024 * 1024]; //省略了读取文件的操作
  }
    public byte[] getData() {
        byte[] dataArray = dataRef.get();
        if (dataArray == null || dataArray.length == 0) {
            dataArray = readImage();
            dataRef = new SoftReference<byte[]>(dataArray);
        }
        return dataArray;
    }
}

在运行上面程序的时候，可以使用 -Xmx 参数来限制JVM可用的内存。由于软引用所指向的对象可能被回收掉，在通过get方法来获取软引用所实际指向的对象的时候，总是要检查该对象是否还存活。

弱引用
弱引用（weak reference）在强度上弱于软引用，通过类WeakReference来表示。它的作用是引用一个对象，但是并不阻止该对象被回收。如果使用一个强引用的话，只要该引用存在，那么被引用的对象是不能被回收的。弱引用则没有这个问题。在垃圾回收器运行的时候，如果一个对象的所有引用都是弱引用的话，该对象会被回收。弱引用的作用在于解决强引用所带来的对象之间在存活时间上的耦合关系。弱引用最常见的用处是在集合类中，尤其在哈希表中。哈希表的接口允许使用任何Java对象作为键来使用。当一个键值对被放入到哈希表中之后，哈希表对象本身就有了对这些键和值对象的引用。如果这种引用是强引用的话，那么只要哈希表对象本身还存活，其中所包含的键和值对象是不会被回收的。如果某个存活时间很长的哈希表中包含的键值对很多，最终就有可能消耗掉JVM中全部的内存。

对于这种情况的解决办法就是使用弱引用来引用这些对象，这样哈希表中的键和值对象都能被垃圾回收。Java中提供了WeakHashMap来满足这一常见需求。

幽灵引用
在介绍幽灵引用之前，要先介绍Java提供的对象终止化机制（finalization）。在Object类里面有个finalize方法，其设计的初衷是在一个对象被真正回收之前，可以用来执行一些清理的工作。因为Java并没有提供类似C++的析构函数一样的机制，就通过 finalize方法来实现。但是问题在于垃圾回收器的运行时间是不固定的，所以这些清理工作的实际运行时间也是不能预知的。幽灵引用（phantom reference）可以解决这个问题。在创建幽灵引用PhantomReference的时候必须要指定一个引用队列。当一个对象的finalize方法已经被调用了之后，这个对象的幽灵引用会被加入到队列中。通过检查该队列里面的内容就知道一个对象是不是已经准备要被回收了。

幽灵引用及其队列的使用情况并不多见，主要用来实现比较精细的内存使用控制，这对于移动设备来说是很有意义的。程序可以在确定一个对象要被回收之后，再申请内存创建新的对象。通过这种方式可以使得程序所消耗的内存维持在一个相对较低的数量。比如下面的代码给出了一个缓冲区的实现示例。

public class PhantomBuffer {
  private byte[] data = new byte[0];
    private ReferenceQueue<byte[]> queue = new ReferenceQueue<byte[]>();
    private PhantomReference<byte[]> ref = new PhantomReference<byte[]>(data, queue);
    public byte[] get(int size) {
        if (size <= 0) {
            throw new IllegalArgumentException("Wrong buffer size");
        }
        if (data.length < size) {
            data = null;
            System.gc(); //强制运行垃圾回收器
             try {
                queue.remove(); //该方法会阻塞直到队列非空
                ref.clear(); //幽灵引用不会自动清空，要手动运行
                ref = null;
                data = new byte[size];
                ref = new PhantomReference<byte[]>(data, queue);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
       }
       return data;
    }
}

public class PhantomBuffer {
  private byte[] data = new byte[0];
    private ReferenceQueue<byte[]> queue = new ReferenceQueue<byte[]>();
    private PhantomReference<byte[]> ref = new PhantomReference<byte[]>(data, queue);
    public byte[] get(int size) {
        if (size <= 0) {
            throw new IllegalArgumentException("Wrong buffer size");
        }
        if (data.length < size) {
            data = null;
            System.gc(); //强制运行垃圾回收器
             try {
                queue.remove(); //该方法会阻塞直到队列非空
                ref.clear(); //幽灵引用不会自动清空，要手动运行
                ref = null;
                data = new byte[size];
                ref = new PhantomReference<byte[]>(data, queue);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
       }
       return data;
    }
}

在上面的代码中，每次申请新的缓冲区的时候，都首先确保之前的缓冲区的字节数组已经被成功回收。引用队列的remove方法会阻塞直到新的幽灵引用被加入到队列中。不过需要注意的是，这种做法会导致垃圾回收器被运行的次数过多，可能会造成程序的吞吐量过低。

引用队列
在有些情况下，程序会需要在一个对象的可达到性发生变化的时候得到通知。比如某个对象的强引用都已经不存在了，只剩下软引用或是弱引用。但是还需要对引用本身做一些的处理。典型的情景是在哈希表中。引用对象是作为WeakHashMap中的键对象的，当其引用的实际对象被垃圾回收之后，就需要把该键值对从哈希表中删除。有了引用队列（ReferenceQueue），就可以方便的获取到这些弱引用对象，将它们从表中删除。在软引用和弱引用对象被添加到队列之前，其对实际对象的引用会被自动清空。通过引用队列的poll/remove方法就可以分别以非阻塞和阻塞的方式获取队列中的引用对象。

参考资料