HashMap 不是線程安全的；請換成Hashtable。

我在本地運(yùn)行了一下 沒發(fā)現(xiàn)死鎖.

你可以用visualvm 檢測一下, 它可以發(fā)現(xiàn)是否死鎖, 已經(jīng)死鎖的行數(shù)等信息

"Thread-1" prio=6 tid=0x00c70bd8 nid=0x914 runnable
兩個線程都是runnable狀態(tài).

這程序,理論上,不應(yīng)該出現(xiàn)死鎖的.

不會發(fā)生死鎖。不是線程安全的hashmap，貌似你也沒有用到鎖的概念。只是到最后map里面的數(shù)據(jù)大于50000.

@nobody
這個知道，現(xiàn)在是想搞明白程序?yàn)槭裁磿ang在那不走了

@Scud(飛云小俠)
應(yīng)該是與機(jī)器有關(guān)，我公司機(jī)器，使用300個循環(huán)就會hang，你可以試著把循環(huán)調(diào)大一點(diǎn)試試看。

突然記起來了.請參考這篇文章:
http://sdh5724.javaeye.com/blog/619130

在自己電腦上,一直無法重現(xiàn)這個問題(無論加大循環(huán),或者增加線程數(shù)),明天回公司再去看看.

@stone2083
非常感謝提供的鏈接。

對，可能是多個線程同時修改HashMap，導(dǎo)致，HashMap內(nèi)部死循環(huán)了。不過奇怪，不管怎么dump thread，都是hang在HashMap.java:420，而查看HashMap的代碼，怎么也想不通這個地方會hang住。

線程還在運(yùn)行，而main函數(shù)已經(jīng)退了，

你在put方法420行的循環(huán)中 加一句
System.out.println(e+" "+e.next);

就會產(chǎn)生一個死循環(huán)，即e=e.next.next。
應(yīng)該是多線程下，進(jìn)行hash處理的時候出現(xiàn)的。

@豬兒笨笨
e.next訪問的是e的一個屬性，怎么會相當(dāng)于e.next.next?

我改成了concurrenthashmap還是會出現(xiàn)，只是出現(xiàn)的頻率降低了不少，大家可以陸續(xù)開上千個進(jìn)程試一下
start javaw TestLock
start javaw TestLock
start javaw TestLock
start javaw TestLock
start javaw TestLock
start javaw TestLock
start javaw TestLock
start javaw TestLock
start javaw TestLock
start javaw TestLock
start javaw TestLock
start javaw TestLock
start javaw TestLock
start javaw TestLock
start javaw TestLock
start javaw TestLock
start javaw TestLock
start javaw TestLock
...........etc

@bigwesthorse
只有hashtable可以順利地通過1429個進(jìn)程測試，哈哈，似乎看到了一點(diǎn)讓人驚喜的東西

死循環(huán)的代碼在hashmap的transfer方法：
void transfer(final Entry[] newTable) {
final Entry[] src = table;
final int newCapacity = newTable.length;
final long time1 = System.currentTimeMillis();
for (int j = 0; j < src.length; j++) {
Entry<K,V> e = src[j];
if (e != null) {
src[j] = null;
do {
final Entry<K,V> next = e.next;
final int i = indexFor(e.hash, newCapacity);
e.next = newTable[i];
newTable[i] = e;
e = next;
} while (e != null);
}
}
}
我的分析是：死循環(huán)就在while中，對同一個舊table中的e，一個線程執(zhí)行了 e.next = newTable[i];（還沒到 e = next;），另一個才到 final Entry<K,V> next = e.next;，結(jié)果后到的線程接著執(zhí)行e = next;造成e=e.next，死循環(huán)了。

樓上的
不是e=e.next
而是e=e.next.next
不過你的分析應(yīng)該是對的，就是在根據(jù)hashcode計(jì)算位置的時候，因?yàn)椴l(fā)的原因出現(xiàn)問題了。

@天快黑了

這個很正常的，因?yàn)閑.next相當(dāng)于一個鏈表指針，指向下一個點(diǎn)，它們是同一個例的實(shí)類。

另外，關(guān)于HashMap的實(shí)現(xiàn)，已經(jīng)說了是線程不安全的，多線程下，出現(xiàn)問題是正常的。

Hashtable一直線程安全，可以放心用。
但說concurrenthashmap不對，這個應(yīng)該不會。
回頭也試一下再來討論。

用了concurrenthashmap，循環(huán)5000次，沒有出現(xiàn)問題。

public TestLock() {


for (int i = 0; i < 5000; i++) {

final int count=i;

Thread t1 = new Thread() {
public void run() {
for (int i = 0; i < 50000; i++) {
map.put(new Integer(i), i);

}
System.out.println(count+" over");
}
};

t1.start();
}
}

@豬兒笨笨
對于concurrenthashmap
用一個批處理寫1000多個start javaw TestLock
肯定會出現(xiàn)的，我說了概率很低，基本上兩三百個程序會有個卡死
你就等著那個批處理狂跑就行了，1到2分鐘之后，你就會感到cpu100%了
被某個進(jìn)程霸占了，一直hang在那里

沒有明白樓上說什么意思？
這樣說吧，是否在一個JVM內(nèi)，還是說同時啟動多個JVM？
如果多個JVM，就很難說有什么問題，比如說用光了資源，等等。

@豬兒笨笨
就是這個程序是否出現(xiàn)死鎖要看rp的，跑個200多次才會出現(xiàn)一次
我用批處理連續(xù)跑了上千次，出現(xiàn)了好幾次死鎖的情況

感謝大家的回復(fù)，這個問題確實(shí)很難解釋清楚。我們只能注意，多線程下千萬不要使用非線程安全的對象。

@豬兒笨笨
ConcurrentHashMap只是保證Happens-before關(guān)系,勉強(qiáng)的線程安全，如果需要保證數(shù)據(jù)一致性，還是用Collections.synchronizedMap(Map map)方法，利用的synchronized機(jī)制，規(guī)劃好代碼流程來實(shí)現(xiàn)線程安全