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

我在本地運行了一下 沒發現死鎖.

你可以用visualvm 檢測一下, 它可以發現是否死鎖, 已經死鎖的行數等信息

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

這程序,理論上,不應該出現死鎖的.

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

@nobody
這個知道，現在是想搞明白程序為什么會hang在那不走了

@Scud(飛云小俠)
應該是與機器有關，我公司機器，使用300個循環就會hang，你可以試著把循環調大一點試試看。

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

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

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

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

線程還在運行，而main函數已經退了，

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

就會產生一個死循環，即e=e.next.next。
應該是多線程下，進行hash處理的時候出現的。

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

我改成了concurrenthashmap還是會出現，只是出現的頻率降低了不少，大家可以陸續開上千個進程試一下
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個進程測試，哈哈，似乎看到了一點讓人驚喜的東西

死循環的代碼在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);
}
}
}
我的分析是：死循環就在while中，對同一個舊table中的e，一個線程執行了 e.next = newTable[i];（還沒到 e = next;），另一個才到 final Entry<K,V> next = e.next;，結果后到的線程接著執行e = next;造成e=e.next，死循環了。

樓上的
不是e=e.next
而是e=e.next.next
不過你的分析應該是對的，就是在根據hashcode計算位置的時候，因為并發的原因出現問題了。

@天快黑了

這個很正常的，因為e.next相當于一個鏈表指針，指向下一個點，它們是同一個例的實類。

另外，關于HashMap的實現，已經說了是線程不安全的，多線程下，出現問題是正常的。

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

用了concurrenthashmap，循環5000次，沒有出現問題。

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
肯定會出現的，我說了概率很低，基本上兩三百個程序會有個卡死
你就等著那個批處理狂跑就行了，1到2分鐘之后，你就會感到cpu100%了
被某個進程霸占了，一直hang在那里

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

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

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

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