困扰了近两月的内存泄露问题终于初见眉目了，罪魁祸首：proxool

恩，对的。
附图：

看起来ConcurrentHashMap对象实例的数量格外的高。你应该检查一下应用程序在什么地方大量用到了这个类。推荐你看看：

http://www.iteye.com/post/676536
http://www.iteye.com/topic/231670

这两个帖子提到在高并发情况下ConcurrentHashMap的锁定问题，有可能是Spring事务配置不合理导致的。

恩，我研究研究这两个帖子。

首先可以肯定是，自己编写的程序没有直接用到过ConcurrentHashMap。
可能用到ConcurrentHashMap的地方，也许是spring，hibernate等类库。
我检查检查

robbin大侠出手了，谢谢谢谢。

事务配置如下：

<bean id="txProxyTemplate" abstract="true"
		class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
		<property name="transactionManager" ref="transactionManager" />
		<property name="transactionAttributes">
			<props>
				<prop key="save*">PROPAGATION_REQUIRED</prop>
				<prop key="update*">PROPAGATION_REQUIRED</prop>
				<prop key="delete*">PROPAGATION_REQUIRED</prop>
				<prop key="remove*">PROPAGATION_REQUIRED</prop>
				<prop key="add*">PROPAGATION_REQUIRED</prop>
				<prop key="modify*">PROPAGATION_REQUIRED</prop>
				<prop key="calculate*">PROPAGATION_REQUIRED</prop>
				<prop key="process*">PROPAGATION_REQUIRED</prop>
				<prop key="noTransaction*">PROPAGATION_NOT_SUPPORTED</prop>
				<prop key="*">PROPAGATION_REQUIRED,readOnly</prop>
			</props>
		</property>
	</bean>

然后所有的manager bean的配置都是类似下面的代码

<bean id="forumAreaManager" parent="txProxyTemplate">
		<property name="target">
			<bean
				class="com.fjt.forum.service.impl.ForumAreaManagerImpl">
				<property name="forumAreaDao" ref="forumAreaDao" />
				<property name="commonTagDao" ref="commonTagDao" />
			</bean>
		</property>
	</bean>

服务器宕机的时的表现是，两个tomcat的java进程所占cpu都是400%左右，用linux top命令看的。
这个时候把catalina.out日志备份后删除，重启tomcat。
事后分析catalina.out日志，发现没有什么特殊的地方，没有不能创建mysql连接、connection消耗尽的情况，都是常规的日志。其中关于jrockit垃圾回收的日志有下面几条

[INFO ][memory ] 35315.048-35332.522: GC 611536K->512771K (920128K), sum of pauses 183.922 ms
***其他的正常日志

[INFO ][memory ] 35359.423: parallel nursery GC 902118K->454118K (920128K), 1766.494 ms
***其他的正常日志

[INFO ][memory ] 35470.454: parallel nursery GC 902118K->511718K (920128K), 3117.067 ms
***其他的正常日志

等Tomcat内存泄漏现象明显的时候 kill -3 pid
等tomcat已经死掉的时候先不要着急重起，再次kill -3 pid

让他dump整个线程堆栈，看看有没有大量被BLOCKED状态的线程，观察一下线程状态。

恩，我试试。

刚才分析堆栈，图片如下：



发现可能tomcat session创建了很多ConcurrentHashMap实例，难道竟然是session影响？

我们程序是不用session的，准备在common.jsp中加上 <%@ page session="false" %>

刚刚看了一个帖子，觉得很有理，大家以为然否？
http://sdyouyun.iteye.com/blog/146275

到现在为止，又平稳的运行一天了。
通过jrmc查看：
tomcat1 线程数66，没有死锁，
tomcat2 线程数70，没有死锁

生成字节码就是编译器的事啊

这三家的编译器javac（就是.java->.class）我都仔细验证过字节码
字符串+都是得到调用StringBuilder.append的字节码，而不是调用String.concat

既然proxool的问题，就还他个清白吧。改一下帖子的标题吧。他醒目了。

我想问一下ThreadLocal的内容不是线程结束后自动被jvm回收吗？需要手动清空？