操作系统：Solaris10
JDK：SUN JDK1.5.0_17
[b]问题补充：[/b]
jmap这个命令我用了，但我发现只是显示出了实例的数量。看不出来哪些对象是在Old区的。你说用Heap工具分析，是什么Heap工具呢？我用了Optimizeit,也是只能看出实例的数量和引用关系，看不出哪些对象是在Old区的。
[b]问题补充：[/b]
我现在的GC策略是这样的，堆最大，最小都是1024m，young区是512m，对象在from和to之间拷贝5次然后扔到old区。回收算法用的是cms。我们的应用对吞吐量的要求比较高，绝大多数都是短生命周期的对象。我在windows下用optimizeit检查了，不存在内存泄漏，但发现在并发量比较大的时候，有几个对象的实例数量是一直在增长的。但当客户端的程序停止的时候，这些对象又是可以被回收的。我们的程序是运行在solaris上的，由于我没下载到optimizeit的solaris安装文件，或者是类似工具的solaris安装文件，因此不确定，olc区中的那些对象是否就是那几个不断增长的对象。我用jvmstat看了，old区涨的很快。而且程序运行大概20分钟左右就core dump了。有的时候会直接把服务器整死。因此我想看看有没有什么手段来看看old区的对象存储的都是什么来帮我肯定一下，就是那几个对象再搞鬼。
[b]问题补充：[/b]
其实这个问题，在昨天临下班之前的10几分钟突然有了进展。终于排查出，我们的程序是没有内存泄漏的。而是由于传输层的拥挤造成的。设置了socket的readReceiveBuffer和sendBuffer之后这个问题得到了缓解。但是为什么会因为传输层的拥挤导致我们old区的对象很多，这点需要再好好研究一下mina框架。
[b]问题补充：[/b]
[quote]根据你的说法， 我觉得你的，配置有问题的， 为什么设计-Xmn512m, 这个是很关键的， 如果你要求很低的world stop. 那么把-Xmn设置到128 或者256m, core dump 的原因可能是因为你CMS机制不起作用， 导致并行收集过多产生的。 另外，也跟你的JAVA的版本有关系。 CMS最好使用JAVA6的版本， 在JAVA5上， 这个技术并不是非常成熟。如果是JAVA5， CMS的启动策略是有BUG的， 这个你可以参考我的BLOG ： http://sdh5724.iteye.com/admin/blogs/283977 [/quote]
young区默认的大小是堆的1/4，但是对于吞吐量优先的程序，可以设置为堆的1/2。因为对象的生命周期短，应该尽可能的让对象在young区就被回收掉，免得被拷贝到old区，再进行回收时，暂停时间会相对较长。网上有些资料显示了，对于吞吐量优先的程序，应该设置一个较大的young区的说法，Sun的网站上也有，将堆设置为3G，young区设置为2G的例子。你说的CMS最好在JAVA6下用，这个我真的不知道。听说JAVA6的GC机制要比JAVA5好。这个我回去试试。
[quote]readReceiveBuffer和sendBuffer 是操作系统参数， 如果你的OS内存很紧张， 也可能导致系统资源不够。 这个参数应该调整成你业务需要的发送接收的大小， 不可以盲目扩大， 每个TCP连接都会占用这个BUFF的大小。 我建议你一般设置成8K。[/quote]
你说的这个我很关系，对这两个参数我也不太了解，但的确是缓解了问题，而且很明显。目前我们只使用了一个TCP连接。对于你说的“这个参数应该调整成你业务需要的发送接收的大小”，我不太明白是什么意思。主要是我不清楚我们需要的大小是多少啊，呵呵。你说的8K，这个是默认配置。但我们使用这个配置时，程序最多只能跑20分钟，程序就死掉了。这涉及到tcp的传输，因为跟我们对接的另一端，他们是C语言写的，目前他们没有设置缓冲区大小，应该用的也是默认的，但C程序我不太了解，不知道是多少。我把这个缓冲区设置为Integer的最大值了，好像是2G（我也觉得有点儿夸张），程序大概跑了四十分钟，服务器宕机了。
[quote]我觉得， 你是不是因为TCP的连接断开后， 没有释放TCP连接？ socket.close（）. 会导致大量的time_wait的连接， 你要仔细看下。 OS会在比较长的时间回收[/quote]
我们现在就一个TCP链接，出现问题时，链接没断过。我们应该是没有内存泄漏的，我用Optimizeit检查了好多次了。
很高兴与你讨论这个问题，我感觉现在问题出现在TCP的缓冲区上，应该让C那边也设置一个较大的缓冲区，然后再看看问题能不能得到解决。
[b]问题补充：[/b]
经过几天的测试，总结如下：
1.机器宕机居然是机器的问题，那个机器，不管上面运行的是我们的应用程序还是模拟器，都会宕机。换了其他的几台服务器，都没出现宕机的问题。
2.buffer的设置：我们一个消息的长度是20个字节。每秒钟2000条消息，就是40000个字节，因次buffer设置为40000。但最后还是没有设置这个值采用默认的。因为问题可能不在这里。
3.目前的问题，使用mina的client接收消息时，每秒钟2000条，大概运行一段时间之后，就会mina就会接收到一个很大的包（100K以上）。这导致我们应用层解析这个消息的时候调用层次过多，抛出stackOverFlow的异常，并且主动把连接关闭了。其实，我们可以修改一下我们的代码，避免抛出这个异常。但这不是问题的根源，因为mina传了一个这么大的数据包给应用层就是不正常的。于是我看了一下mina的代码，在read的时候，会根据接收到的消息的长度，来调整allocate的长度。这个上限是receiveByteBuffer的2倍。我尝试修改了mina的代码，让他每次固定allocate 1024个字节。但是问题依然存在，目前没找到解决方法。为了规避这个问题，只是让服务端不给我们发送这个应答，这在业务上是允许的。但没找到问题的根源总是感觉心里堵的荒，打算试试grizzly。
