java线程安全问题

1.做了个测试，使用HashMap ,多个线程做put get ,remove等操作，模拟类似tomcat存放session的数据结构
只是我在put,get remove时没有加同步锁，（线程不安全），用LR做压力测试,cpu很快就达到100%,但是令我不解的是
我停止LR测试时，cpu还是居高不下，即使过了2个多小时仍是如此，就跟程序进入了死循环一样，除非停止这个java程序,线程dump的信息，大多线程都是在对这个HashMap的get操作上，如果加上同步锁（线程安全），则没有以上问题

2.我不解的是，难道线程不安全会导致死循环?能不能有什么技术手段检测HashMap是否死循环?

以上我修改tomcat代码做过测试，session操作是线程不安全的，只是tomcat cpu没有达到100%,但一直是50%,停止压力测试后，一直是50%，就跟上述说的现象类似
如果不是死循环，那是什么导致cpu一直保持不变呢？
[该贴被windgoogle于2008-12-29 16:23修改过]

在一个错误的过程中有时候很难找到一个合理的解释，因为不能确切的知道这个过程里都发生了什么。

所以想找个办法，让这些不确切变得确切

hashmap map = new hashmap(X) //X是根据你的线程数量，尽可能的大，你试验一下。

试过了，不管用，tomcat最大线程数150,我x设到1000,情况依旧，

没有道理,这没道理产生死锁

1000太小了，至少65535

想问一下设置hashmap的初始大小的用意，我也怀疑是hashmap扩容时因线程不安全产生死循环，但没有办法验证，不过hashmap初始大小，大和小，在此问题上有差别吗？

应该没有死锁，因为用jprofile检测了一下，没有死锁，再说如果是死锁，所有线程应该都在等待某个锁，没有干实际的活，这时cpu应该很空闲才对，所以我觉得是某个线程或多个线程在执行操作hashmap时进入死循环，所以线程一直保持运行状态，这跟jpofier监控看到的情况差不多，我的问题是我没有办法确定是否真正的在操作hashmap进人了死循环,jprofiler好像没有能跟综到hashmap内部的功能

修改之后可以了么？？如果不行可以改得更大一些。

这会造成死循环，这个问题在年初我玩小游戏时遇到过。


for (Entry<K,V> e = table[indexFor(hash, table.length)];
             e != null;
             e = e.next)

上面是HashMap之get的部分代码，看看e.next是否为空，我推测如果不同步这应该永不为空，您应该发现您的多CPU都在HashMap.get处停止了。
看看这个：http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423457
SUN不认为这是bug，推荐采用ConcurrentHashMap完成类似场景。

关注一下

关注一下

freebox 的说法最初跟我的猜想一样，我也是看了这段代码觉得有死循环的可能，但是没有办法验证

下页