資訊專欄INFORMATION COLUMN
摘要：前言在上文源碼分析原理中分析了的相關(guān)原理。我在北京模擬執(zhí)行你在哪兒回復(fù)最后執(zhí)行結(jié)果開始提問提問完畢，我去干其他事了收到消息你在哪兒等待響應(yīng)中。。。。?；貜?fù)我在北京這樣一個(gè)模擬的異步事件回調(diào)就完成了。
前言
在上文「Guava 源碼分析（Cache 原理）」中分析了 Guava Cache 的相關(guān)原理。
文末提到了回收機(jī)制、移除時(shí)間通知等內(nèi)容，許多朋友也挺感興趣，這次就這兩個(gè)內(nèi)容再來分析分析。
在開始之前先補(bǔ)習(xí)下 Java 自帶的兩個(gè)特性，Guava 中都有具體的應(yīng)用。Java 中的引用
首先是 Java 中的引用。
在之前分享過 JVM 是根據(jù)可達(dá)性分析算法找出需要回收的對(duì)象，判斷對(duì)象的存活狀態(tài)都和引用有關(guān)。
在 JDK1.2 之前這點(diǎn)設(shè)計(jì)的非常簡單：一個(gè)對(duì)象的狀態(tài)只有引用和沒被引用兩種區(qū)別。
這樣的劃分對(duì)垃圾回收不是很友好，因?yàn)榭傆幸恍?duì)象的狀態(tài)處于這兩之間。
因此 1.2 之后新增了四種狀態(tài)用于更細(xì)粒度的劃分引用關(guān)系：
強(qiáng)引用（Strong Reference）:這種對(duì)象最為常見，比如 A a = new A();這就是典型的強(qiáng)引用；這樣的強(qiáng)引用關(guān)系是不能被垃圾回收的。
軟引用（Soft Reference）:這樣的引用表明一些有用但不是必要的對(duì)象，在將發(fā)生垃圾回收之前是需要將這樣的對(duì)象再次回收。
弱引用（Weak Reference）:這是一種比軟引用還弱的引用關(guān)系，也是存放非必須的對(duì)象。當(dāng)垃圾回收時(shí)，無論當(dāng)前內(nèi)存是否足夠，這樣的對(duì)象都會(huì)被回收。
虛引用（Phantom Reference）:這是一種最弱的引用關(guān)系，甚至沒法通過引用來獲取對(duì)象，它唯一的作用就是在被回收時(shí)可以獲得通知。
事件回調(diào)事件回調(diào)其實(shí)是一種常見的設(shè)計(jì)模式，比如之前講過的 Netty 就使用了這樣的設(shè)計(jì)。
這里采用一個(gè) demo，試下如下功能：
Caller 向 Notifier 提問。
提問方式是異步，接著做其他事情。
Notifier 收到問題執(zhí)行計(jì)算然后回調(diào) Caller 告知結(jié)果。
在 Java 中利用接口來實(shí)現(xiàn)回調(diào)，所以需要定義一個(gè)接口：
public interface CallBackListener {
/**
* 回調(diào)通知函數(shù)
* @param msg
*/
void callBackNotify(String msg) ;
}
Caller 中調(diào)用 Notifier 執(zhí)行提問，調(diào)用時(shí)將接口傳遞過去：
public class Caller {
private final static Logger LOGGER = LoggerFactory.getLogger(Caller.class);
private CallBackListener callBackListener ;
private Notifier notifier ;
private String question ;
/**
* 使用
*/
public void call(){
LOGGER.info("開始提問");
//新建線程，達(dá)到異步效果
new Thread(new Runnable() {
@Override
public void run() {
try {
notifier.execute(Caller.this,question);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}).start();
LOGGER.info("提問完畢，我去干其他事了");
}
//隱藏 getter/setter
}
Notifier 收到提問，執(zhí)行計(jì)算（耗時(shí)操作），最后做出響應(yīng)（回調(diào)接口，告訴 Caller 結(jié)果）。
public class Notifier {
private final static Logger LOGGER = LoggerFactory.getLogger(Notifier.class);
public void execute(Caller caller, String msg) throws InterruptedException {
LOGGER.info("收到消息=【{}】", msg);
LOGGER.info("等待響應(yīng)中。。。。。");
TimeUnit.SECONDS.sleep(2);
caller.getCallBackListener().callBackNotify("我在北京！");
}
}
模擬執(zhí)行：
public static void main(String[] args) {
Notifier notifier = new Notifier() ;
Caller caller = new Caller() ;
caller.setNotifier(notifier) ;
caller.setQuestion("你在哪兒！");
caller.setCallBackListener(new CallBackListener() {
@Override
public void callBackNotify(String msg) {
LOGGER.info("回復(fù)=【{}】" ,msg);
}
});
caller.call();
}
最后執(zhí)行結(jié)果：
2018-07-15 19:52:11.105 [main] INFO c.crossoverjie.guava.callback.Caller - 開始提問 2018-07-15 19:52:11.118 [main] INFO c.crossoverjie.guava.callback.Caller - 提問完畢，我去干其他事了 2018-07-15 19:52:11.117 [Thread-0] INFO c.c.guava.callback.Notifier - 收到消息=【你在哪兒！】 2018-07-15 19:52:11.121 [Thread-0] INFO c.c.guava.callback.Notifier - 等待響應(yīng)中。。。。。 2018-07-15 19:52:13.124 [Thread-0] INFO com.crossoverjie.guava.callback.Main - 回復(fù)=【我在北京！】
這樣一個(gè)模擬的異步事件回調(diào)就完成了。
Guava 的用法Guava 就是利用了上文的兩個(gè)特性來實(shí)現(xiàn)了引用回收及移除通知。
引用可以在初始化緩存時(shí)利用：
CacheBuilder.weakKeys()
CacheBuilder.weakValues()
CacheBuilder.softValues()
來自定義鍵和值的引用關(guān)系。
在上文的分析中可以看出 Cache 中的 ReferenceEntry 是類似于 HashMap 的 Entry 存放數(shù)據(jù)的。
來看看 ReferenceEntry 的定義：
