首先感谢阿宝同学的帮助，我才对这个gc算法的调整有了一定的认识，而不是停留在过去仅仅了解的阶段。在读过sun的文档和跟阿宝讨论之后，做个小小的总结，如果有谬误，敬请指正。    CMS，全称Concurrent Low Pause Collector，是jdk1.4后期版本开始引入的新gc算法，在jdk5和jdk6中得到了进一步改进，它的

记一次Java GC调整经历 由于Boss看了某JVM GC调整的文章，兴致大发叫嚷要对我们的服务进行调优，于是开始了一次调优经历。 由于服务是属于非后台计算类型，因此抛弃了并行回收策略，而使用并发回收，对年轻代做并行回收，年老代做并发回收，参数 引用 -Xms2048m -Xmx2048m -Xmn512m -XX:ParallelGCThreads=8 -XX:+UseCo

JDK5.0垃圾收集优化之–Don’t Pause       作者：江南白衣，最新版链接：http://blog.csdn.net/calvinxiu/archive/2007/05/18/1614473.aspx，版权所有，转载请保留原文链接。       原本想把题目更简单的定为–《不要停》的，但还是自己YY一下就算

jvm 的GC日志初体验关于GC的一些参数-verbose.gc开关可显示GC的操作内容。打开它，可以显示最忙和最空闲收集行为发生的时间、收集前后的内存大小、收集需要的时间等。打开-xx:+ printgcdetails开关，可以详细了解GC中的变化。打开-XX: + PrintGCTimeStamps开关，可以了解这些垃圾收集发生的时间，自JVM启动以后以秒计量。

其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可 进行设置     实例，以下给出1G内存环境下java jvm 的参数设置参考： JAVA_OPTS=”-server -Xms800m -Xmx800m  -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.a

JVM参数调优是一个很头痛的问题，可能和应用有关系，下面是本人一些调优的实践经验，希望对读者能有帮助，环境LinuxAS4,resin2.1.17,JDK6.0,2CPU,4G内存,dell2950服务器，网站是http://shedewang.com一：串行垃圾回收，也就是默认配置，完成10万request用时153秒，JVM参数配置如下$JAVA_ARGS .= ” -Dresin.home=$SERVER

1 资料 JDK5.0垃圾收集优化之–Don’t Pause(花钱的年华)   编写对GC友好，又不泄漏的代码(花钱的年华)   JVM调优总结   JDK 6所有选项及默认值   2 GC日志打印   GC调优是个很实验很伽利略的活儿，GC日志是先决的数据参考和最终验证： -XX:+PrintGCDetails -XX:+PrintGCTimeStamps(GC发生的时间

调整JVM GC(Garbage Collection)，可以极大的减少由于GC工作，而导致的程序运行中断方面的问题，进而适当的提高Java程序的工作效率。但是调整GC是以个极为复杂的过程，由于各个程序具备不同的特点，如：web和GUI程序就有很大区别（Web可以适当的停顿，但GUI停顿是客户无法接受的），而且由于跑在各个机器上的配置不同（主

 众所周知，jvm的内存是受限的，一为机器的体系架构，二为操作系统本身。x86,x86-64,SPARC,…..的内存映射是不同，而各操作系统的内存管理机制也有区别。以下是来自http://fengyouhua.javaeye.com/blog/58170  1. Heap设定与垃圾回收Java Heap分为3个区，Young，Old和Permanent。Young保存刚实例化的对象

配置tomcat使用jconsole 修改catalina脚本 Windows平台：修改catalina.bat，在dorun和dostart段开头增加一行（注意是一行）： set JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=”9004″ -Dcom.sun.management.jmxremote.authenticate=”false” -Dcom.sun.manageme