前段時(shí)間在項(xiàng)目中遇到一個(gè)問(wèn)題。當(dāng)多個(gè)系統(tǒng)同時(shí)運(yùn)行時(shí)，大部分系統(tǒng)能夠良好運(yùn)轉(zhuǎn)，部分卻卡死在了啟動(dòng)界面。以下是我解決該問(wèn)題的步驟和總結(jié)：

1、復(fù)現(xiàn)問(wèn)題。重新走了一遍出問(wèn)題的過(guò)程，發(fā)現(xiàn)問(wèn)題的確存在。說(shuō)明這個(gè)問(wèn)題不是偶然發(fā)生。

2、看日志。確定問(wèn)題是必然發(fā)生之后，開(kāi)始查看日志，發(fā)現(xiàn)日志中有問(wèn)題的系統(tǒng)狀態(tài)一直不正常。一直處于任務(wù)過(guò)期的狀態(tài)。一個(gè)系統(tǒng)對(duì)應(yīng)一個(gè)任務(wù)，任務(wù)過(guò)期之后，系統(tǒng)就處于卡死狀態(tài)。系統(tǒng)的邏輯是這樣的：當(dāng)啟動(dòng)系統(tǒng)的時(shí)候，會(huì)發(fā)起多個(gè)請(qǐng)求，每個(gè)請(qǐng)求會(huì)產(chǎn)生一個(gè)任務(wù)，同時(shí)將這些任務(wù)寫(xiě)到緩存(HashMap)和數(shù)據(jù)庫(kù)。任務(wù)的狀態(tài)(包括數(shù)據(jù)庫(kù)和緩存)會(huì)隨著任務(wù)的進(jìn)度而發(fā)生改變。

任務(wù)過(guò)期意味著該任務(wù)已經(jīng)執(zhí)行完畢或者從來(lái)沒(méi)有這個(gè)任務(wù)。

如果說(shuō)任務(wù)已經(jīng)執(zhí)行完畢導(dǎo)致這個(gè)問(wèn)題的話(huà)，這個(gè)是不可能的。因?yàn)閷?duì)于每個(gè)任務(wù)，當(dāng)他執(zhí)行成功或者失敗時(shí)，垃圾回收器會(huì)在15分鐘后對(duì)任務(wù)進(jìn)行清理。事實(shí)上，當(dāng)我們一開(kāi)啟系統(tǒng)時(shí)，就觀察到該系統(tǒng)對(duì)應(yīng)的任務(wù)在數(shù)據(jù)庫(kù)中存在，但是在緩存中卻不存在！就是說(shuō)，當(dāng)我們從HashMap 中獲取相應(yīng)的任務(wù)時(shí)，獲取到的值是不存在的！為什么獲取到的值會(huì)不存在呢？這可能有兩種原因：

(1)任務(wù)根本就沒(méi)有寫(xiě)入緩存；

(2)任務(wù)寫(xiě)入緩存后很快被清理掉了；

但是根據(jù)以上的分析，任務(wù)被很快清理掉是不可能的。因?yàn)橹辽俚迷?5分鐘之后，才能清理。那就只有第一種可能了：任務(wù)根本沒(méi)有寫(xiě)入緩存！

開(kāi)始著手看代碼。發(fā)現(xiàn)寫(xiě)入緩存的關(guān)鍵一行代碼：

MyMap.getInstance().put(taskId,"hello");

繼續(xù)跟蹤MyMap，主要的類(lèi)相關(guān)內(nèi)容如下：

publicclass?MyMap {

privateMapmap=newHashMap();

privateObjectlock=newObject();

privatestaticMyMapinstance?=newMyMap();

privateMyMap(){}

publicstaticMyMap getInstance() {

if(instance?==null) {

instance=new?MyMap();

}

returninstance?;

}

publicvoidput(Integer taskId, String name) {

synchronized(lock?) {

map.put(taskId, name);

}

}

publicMap getMap() {

returnmap?;

}

}

該類(lèi)使用單例模式，使用HashMap來(lái)保存所有的任務(wù)。每次執(zhí)行一個(gè)任務(wù)，都會(huì)將這個(gè)任務(wù)寫(xiě)入緩存。然后根據(jù)taskId獲取相應(yīng)的任務(wù)。這段代碼看起來(lái)沒(méi)有多大問(wèn)題。

但是在高并發(fā)的情況下，這個(gè)單例是不安全的：

publicstaticMyMap getInstance() {

if(instance?==null) {

instance=new?MyMap();

}

returninstance?;

}

在多個(gè)線(xiàn)程同時(shí)請(qǐng)求getInstance時(shí)，某個(gè)線(xiàn)程，判斷instance == null 為true,會(huì)繼續(xù)執(zhí)行instance = new MyMap();

這行代碼會(huì)先new MyMap()，在heap上分配內(nèi)存空間，然后將instance 指向該內(nèi)存地址。在instance 未指向該內(nèi)存空間時(shí)，如果其他線(xiàn)程也調(diào)用getInstance時(shí)，發(fā)現(xiàn)instance == null 為真，也會(huì)執(zhí)行new MyMap()。這時(shí)，不同的線(xiàn)程拿到的就不是同一個(gè)實(shí)例了。調(diào)用put后，會(huì)將不同的數(shù)據(jù)寫(xiě)入到不同對(duì)象對(duì)應(yīng)的map中。所以我們拿到的實(shí)例有可能是所有線(xiàn)程共享的實(shí)例，也有可能是某些線(xiàn)程共享的實(shí)例，當(dāng)然我們就只能獲取到部分?jǐn)?shù)據(jù)，另外的數(shù)據(jù)就丟失了。或者說(shuō)數(shù)據(jù)依然在某個(gè)內(nèi)存中，但是我們丟失了指向該數(shù)據(jù)的引用。所以部分任務(wù)就這么丟失了，導(dǎo)致系統(tǒng)處于卡死狀態(tài)。

如何來(lái)處理這種不安全的單例呢？

使用兩種方式可以解決：

(1)給getInstance()方法添加關(guān)鍵字synchronized,保證當(dāng)前只有一個(gè)線(xiàn)程執(zhí)行該方法。

public synchronizedstaticMyMap getInstance() {

if(instance?==null) {

instance=new?MyMap();

}

returninstance?;

}

(2)

privatestatic?MyMapinstance=newMyMap();

privateMyMap(){}

publicstaticMyMap getInstance() {

returninstance?;

}

第一種方式使用效率較低。第二種方式在類(lèi)加載時(shí)便生成對(duì)象。沒(méi)有使用類(lèi)的延遲加載。

另外還有兩種方式可以實(shí)現(xiàn)：內(nèi)部靜態(tài)類(lèi)和雙重校驗(yàn)鎖(暫且不討論)。

通過(guò)這兩種方式，即可以解決單例模式的線(xiàn)程安全問(wèn)題。同時(shí)，為了提高效率，將緩存從HashMap改為ConcurrentHashMap.

總結(jié)

以上是生活随笔為你收集整理的java 单例 缓存hashmap_java 、HashMap 和单例的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。