以前我作为java开发人员，用的都是sun的JVM（这也是当今最好用的虚拟机），由于垃圾收集的工作都是交给JVM做，只要编码的时候注意不要在静态的集合对象中只添加对象，而不删除对象的情况发生，就可以避免内存泄漏，所以自己从没有认真考虑过要将GC好好学习一下；然而实际的工作表明，不深入的学习GC的原理，很难解决生产中的问题。
学习开始从理解JVM的GC工作原理入手。垃圾收集的过程主要分三个步骤：标记（mark），清除（sweep），整理（compact）。标记过程就是看看在JVM堆中有哪些对象还有用，哪些对象不用了，有用的对象就作个标记，不用的对象就不作标记；对未作标记的对象（即不用的对象）就作第二步清除；当清除完以后，由于有用的对象此时是分散的分布在JVM堆中，JVM堆就会有许多堆碎片，因而需要做第三步整理；整理（也有人翻译成“压缩”，实际上最准确的翻译是“使紧凑”）就是将散放在JVM堆中的有用对象移动到堆底部，削除堆碎片。
然而，原理虽然简单，可各个厂商在对GC的具体实现上却有区别，从而导致相同的应用，在不同的JVM上会出现不同问题。现在我们主要看看IBM JVM GC和SUN JVM GC的实现方式和行为。
java与C/C++在内存泄露上定义不同，java上内存泄露是说持有了不该再持有的对象
SUN的JVM采用分代垃圾收集（generational garbage collection）的方式，从JDK1.4.1开始，它将JVM堆栈分成三个部分：年轻代（young generation）、年老代（old/tenured generation）和持久代（permanent generation）。关于分代垃圾收集的详细介绍请查阅参考文献（[25]、[26]）。
<!-- [if gte vml 1]> <![endif]-->
持久代用于存储装载的类、方法对象（Class对象和Method对象）和其它相关的元数据，默认大小为4MB。以下是几个常用的设置持久代的JVM参数：
-XX:PermSize=4m 设定持久代的大小
-XX:MaxPermSize=64m 设定持久代大小的最大值
-Xnoclassgc 禁止对持久代进行收集
对于年轻代和年老代的设定，是基于这样的统计分析结果：在绝大多数的应用程序中，一些对象在创建后很快成为了垃圾，这部分对象占到了新创建对象的90%以上；而另一些对象，数目相对较少，但要长期驻留在内存中；于是对于这两种存活时间不同的对象，SUN的JVM将堆分出了两个不同的区域，采用不同算法进行收集。SUN的JVM通过不同的收集器实现不同的收集算法。下面就详细介绍几种收集器，以及在这两个代中所采用的收集器。
复制收集器（Copying Collector）：堆被分成两个大小相等的空间，其中一个为活跃的空间用于分配对象，另一个为不活跃的空间未使用；当用于分配的空间占满后，程序就会停止，活跃的对象被从活跃的空间复制到不活跃的空间中；复制完成后，空间的角色就会转换，原来不活跃的空间成为了新的活跃空间。由于活跃的对象直接被复制到不活跃的空间，所以此过程并不存在标记这个步骤。
标记-清除收集器（Mark and Sweep Collector）：在标记过程中，死对象所占用的地址空间将被记录在专门的表中；标记过程结束后，相邻的死对象所占的空间将合并在一起，由于此收集器不整理堆，将会产生越来越多的堆碎片。
标记-整理收集器（Mark and Compact Collector）：在标记过程中，给活的对象或死的对象做标记；标记过程结束后，将堆中活对象复制到堆的底部，使这些活的对象紧凑的排列在一起，避免堆碎片产生；在执行此收集过程中将停止所有应用程序线程的执行。
在年轻代主要采用复制收集器进行收集。实际上SUN的JVM对此收集器做了一些改进，它将年轻代分为一个创建空间（eden space）和两个残存空间（survivor space）。小的收集将活的对象从创建空间和一个残存空间复制到另一个残存空间；然后将创建空间和另一个残存空间看成是一个整体，分配对象；当空间被占满，就将活的对象从创建空间和另一个残存空间复制到第一个残存空间；如此反复。若残存空间过小，部分活的对象将溢出到年老代，从而增加了年老代的的收集频率，由于在年老代进行的收集所花的时间远多于在年轻代进行的收集，运行系统性能就会恶化，所以合理设置残存空间的大小，可以对JVM进行调优。以下是几个常用的设置年轻代的JVM参数：
-XX:SurvivorRatio=8 设定创建空间和残存空间之间的大小比率
-XX:MaxTenuringThreshold=0 设定残存空间期限阈值（Tenuring Threshold）
-XX:NewSize=size 设定年轻代的大小（字节）
-XX:MaxNewSize=size 设定年轻代的最大大小（字节）
-XX:NewRatio=2 设定年轻代和年老代之间的大小比率
在年老代主要采用标记-清除收集器和标记-整理收集器进行收集。
SUN的JVM中还有其它几种收集器，包括增量收集器（Incremental Collector）、并行复制收集器（ParallelCopying Collector）、并行清除收集器（Parallel Scavenge Collector）和并发标记-清除收集器（Concurrent Mark-Sweep(CMS) Collector）等。并行复制收集器和并发标记-清除收集器基本上是默认的复制收集器和标记-清除收集器的并发版本。这些一般在多CPU和大内存的条件下设置，关于并行复制收集器和并发标记-清除收集器的详细介绍请查阅参考文献（[20]），关于这些收集器的详细介绍请查阅参考文献（[27]、[28]、[29]、[31]）。
-XX:+UseParNewGC 启用年轻代并行复制收集器，它将垃圾收集的工作分为与CPU数量一样多的线程。可以和-XX:+UseConcMarkSweepGC一起使用。
-XX:+UseParallelGC 启用年轻代并行清除收集器，针对多处理器系统上非常大(G字节以及更大的)堆进行了优化。不可以和-XX:+UseConcMarkSweepGC一起使用。
-XX:+UseConcMarkSweepGC 启用年老代并发标记-清除收集器，它在初始标记阶段（及在以后暂短重新标记阶段）暂短地停止整个系统，然后恢复用户程序，同时垃圾收集器线程与用户程序并发地执行
SUN的JVM作GC时分小收集（minor collection）和大收集（major collection）。小收集只在年轻代中作GC。大收集先在年轻代作GC，再在年老代作GC，因此大收集将花去更多的时间。可以通过-Xloggc:filename和-verbose:gc开启GC日志，关于更详细的GC日志设置请查阅参考文献（[29]）。
以上是对SUN的JVM的实现和性能调优的简单介绍，关于这些收集器的详细介绍请查阅参考文献（SUN JVM资料）
由于对象的引用方式的不同，JVM的收集策略也不同。Java对象的引用方式分为：强引用（strong reference）、软引用（soft reference）、弱引用（weak reference）和虚引用（phantom reference）。因此根据访问方式，对象也就分为如下4种：
强可及对象（strongly reachable）：可以通过强引用访问的对象。它将一直占有堆空间，在JVM报告内存不足的情况下也不会释放。
软可及对象（softly reachable）：不是强可及对象，并且能够通过软引用访问的对象。在JVM报告内存不足时，才考虑将它释放；只要内存不太紧张，就会保留该对象。关于软引用的具体运用请查阅参考文献（[13]）
弱可及对象（weakly reachable）：不是强可及对象也不是软可及对象，并且能够通过弱引用访问的对象。JVM随时都会将它释放。关于弱引用的具体运用请查阅参考文献（[12]）
虚可及对象（phantomly reachable）：不是强可及对象、软可及对象，也不是弱可及对象，已经结束的，可以通过虚引用访问的对象。JVM已经执行完finalize()方法，随时都会将它释放。
对于软引用、弱引用和虚引用的实现，java中定义了3个引用类：SoftReference、WeakReference和PhantomReference。
SoftReference对象或WeakReference对象都是先将referent域被设置为null；然后它们引用过的heap对象被声明为 finalizable；最后，当heap对象的finalize()方法被运行而且该对象占用的内存被释放，SoftReference对象或WeakReference对象就被添加到它的引用队列（ReferenceQueue）
PhantomReference对象与SoftReference对象或WeakReference对象的最大区别在于，SoftReference对象或WeakReference对象是在它们所引用的对象被垃圾收集器收集之后被添加到ReferenceQueue，而PhantomReference对象是在它所引用的对象被垃圾收集器收集之前添加到ReferenceQueue。因此，虚可及对象存在最后一次被找回的机会。关于引用类的详细使用请查阅参考文献（[10]、[11]）
IBM的JVM在1.5.0以前，默认采用经典的三步式垃圾收集策略，即标记-清除-整理（mark-sweep-compact）。它没有像SUN的JVM那样将堆分成三个代，而是只有一个区域。在堆空间底部会分配一个K簇（k-cluster），它是专门用来存储“类块”（class block）的区域。当K簇满了的情况下，在P簇（p-cluster）中继续分配类块。有些对象永远或者临时无法移动，这些固定不动的对象就是常说的pinned对象。P簇就是用来存贮这些pin对象的。新的P簇可以被分配到任何地方而且又不能被移动，这就容易造成碎片问题。为了解决这些问题，IBMJDK 1.4.2版本中起用了pinnedFreeList来改变P簇的分配方法。同时提供了命令行参数对K簇和P簇的大小进行配置。关于K簇和P簇更详细的介绍请查阅参考文献（[55]）。
从IBM JDK 1.5.0开始，它的垃圾收集策略有4种，关于垃圾收集策略的详细介绍请查阅参考文献（[54]）：
-Xgcpolicy:optthruput 是默认策略，采用标记-清除-整理收集器，针对吞吐量进行优化。然而，由于标记栈大小固定并且无法设置，当堆中有大量对象生成时，显然标记栈会不够用，标记栈溢出（mark stack overflow）将会产生。
-Xgcpolicy:optavgpause 会启用同步标记，针对停顿时间进行优化，这将减少暂停时间并且让暂停时间长度在堆空间占用率上升的时候更稳定。然而，这个参数将减少系统吞吐量大约5%，当然这一数值将因程序不同而有一定差异。
-Xgcpolicy:gencon 分代并发，从IBM JDK 1.5.0开始加入。类似于SUN的JVM的分代收集，但年老代是采用并发标记并且年轻代两个半空间大小相等。
-Xgcpolicy:subpool 子池，这种策略只能在AIX平台上使用。
除以上4种垃圾收集策略外，还有其它参数会改变GC的行为：
-Xcompactgc 强制进行整理
-Xnocompactgc 不进行整理
-Xgcthreads 设置GC辅助线程的个数，打开-Xgcpolicy:optavgpause时才有用
想要打印GC日志，使用-verbosegc或-verbose:gc，关于IBM JVM原理的更详细介绍请查阅参考文献（[50]、[53]）。
下面，我们就将SUN的JVM和IBM的JVM做个对比：
a. IBM的JVM采用标记-清除-整理收集器，这种方式的最大弊端就是在需要生成大量对象的应用中，标记栈会不够用，再由于IBM的JVM标记栈大小固定并且无法设置，标记栈溢出将会产生；而SUN的JVM就不会有这样的问题。SUN的JVM由于采用分代收集策略，在年轻代采用复制收集器，它不必为生成的大量对象作标记，只是将活着的对象复制到另一个区域；而在年老代采用标记-整理收集器，虽使用标记栈，但由于这些对象是长期存在于JVM中的，且数量相对较少，所以不会出现标记栈溢出的问题。标记栈溢出一旦发生，系统性能将骤然下降，且无法恢复，关于标记栈溢出的详细介绍请查阅参考文献（[53],Part 2 Garbage collection、[51]）。IBM自己也认识到这个收集器存在的问题，从JDK 1.5.0开始，引入了分代收集策略，算是解决了这个问题，但SUN的JVM早在JDK1.3就采了分代收集策略，不知为何IBM采用此方式如此之晚？
b.在JDK 1.5.0以前，IBM的JVM由于没有分代，类的类对象和其它一些元数据不像SUN的JVM一样放在持久代中，而是首先放在堆底部的K簇中，当K簇容纳不下时，就会在堆中的可用空间中分配固定大小的P簇来存放，这些P簇散放在堆中，即无法收集也无法移动，所以IBM的JVM非常容易产生堆碎片。IBMJDK 1.4.2版本中起用了pinnedFreeList来改变P簇的分配方法，在分配新的P簇之前会作GC，然后尽量在堆的底部分配P簇。这种方法基本上解决了堆碎片问题。除了P簇中存放的pinned对象外，永远或者临时无法移动的对象还包括dosed对象。pinned对象是被native引用的对象，包括Thread对象、类的Class对象；dosed对象是被线程栈引用的对象。dosed对象除非线程栈主动释放，否则也无法移动。关于dosed对象的一些信息请查阅参考文献（[53],Part 1 Object allocation;Part 2 Garbagecollection）。
JVM异常诊断与性能调优:
Java程序的性能问题主要由几方面原因造成：
1． 某些对象在运行一段时间后，占用大量内存资源不释放，甚至占用内存资源越来越多，导致内存泄漏。
2． 某些线程上的某些方法由于长时间运行，占用大量CPU时间，导致系统性能下降。
3． 有死锁或资源争用的情况存在，造成某些线程长期等待。
对于以上性能问题的监控、诊断和分析，各个JVM厂商以及应用服务器厂商都提供了不同的方法或工具，下面就做简要介绍：
Sun的JVM提供了多种方式对性能进行监控和分析：
从JDK1.4.1开始，Sun的JVM支持使用命令jvmps、jvmstat和perfagent；从JDK1.5.0开始，这些命令相应变为jps、jstat和jstatd。
jstat 列出指定JVM实例中的各个分代的使用情况，GC运行情况等，并且此过程是实时的
jstatd 本地jstat守护进程，可让远程jstat访问本地JVM
关于jps、jstat和jstatd的更详细的介绍请查阅（[32]、[33]）。
添加JVM参数 -verbose:gc或者 -Xloggc:filename，生成GC日志。
通过分析GC日志可以粗略的了解JVM堆的使用情况。例如，可以知道什么时候GC比较频繁，说明此时java程序正在大量分配对象；若JVM堆的占用不断在增长，说明java程序可能存在内存泄漏的情况；若GC的执行时间非常长，可能堆的最大值设得比较小。参考资料中有一个例子说明如何分析和调优GC性能（[21]）。有一些图形化的工具可以帮助分析GC日志，例如JTune等。
为了得到更详细的GC信息，可以使用如下JVM参数：
-XX:-PrintGCDetails
-XX:-PrintGCTimeStamps
-XX:-PrintTenuringDistribution 打印出对象在放入年老代之前在年轻代做了多少次复制
关于GC日志的更详细的介绍请查阅（[29]、[53]、[54]）。
通过设置不同的JVM参数可以得到含有不同信息的hprof文件，下面是一些比较常用的参数设置：
-agentlib:hprof=file=file,format=b 创建堆转储，将堆转储导入指定文件
-agentlib:hprof=heap=dump 创建堆转储，获取堆快照
-agentlib:hprof=heap=sites 跟踪堆的分配
-agentlib:hprof=cpu=samples线程的CPU占用时间
-agentlib:hprof=cpu=times 方法的CPU占用时间
在JDK1.5.0以前使用-Xrunhprof；从JDK1.5.0开始改用-agentlib:hprof，-Xrunhprof仍然可以使用。可以使用PerfAnal或HAT对hprof文件进行分析。
关于hprof的更详细的介绍请查阅（[34]、[35]、[36]、[37]）。
从JDK1.5.0开始，Sun提供了JVM实时监控工具JConsole。它是JMX兼容的图形化监控工具，它可以监控本地或远程的JVM实例。添加JVM参数-Dcom.sun.management.jmxremote使应用程序启动管理代理，这样启动JConsole后就可以找到这个应用并实时监控。JConsole可以监控内存、线程、操作系统等，它可对线程进行分析并诊断出死锁。
关于JConsole的更详细的介绍请查阅（[38]、[39]）。
添加JVM参数-verbose:gc，生成的GC日志可以用以下工具分析：
IBM Pattern Modeling andAnalysis Tool for Java Garbage Collector http://www.alphaworks.ibm.com/tech/pmat
Diagnostic Tool for JavaGarbage Collector http://www.alphaworks.ibm.com/tech/gcdiag
关于如何打印和分析GC日志，可参考（[55],Part 3 verbosegc and command-line parameters、[59]）
下面对最一般的GC格式作简单介绍：
<GC(4): GC cycle started Fri Apr 0414:27:20 2008
<GC(4): freed 34873824 bytes, 84% free(451978888/536869376), in 78 ms>
<GC(4): mark: 69 ms, sweep: 9 ms, compact:0 ms>
<GC(4): refs: soft 0 (age >= 32), weak0, final 329, phantom 0>
第一行：此次GC发生的时间；
第二行：已释放34873824字节，释放完以后JVM堆有84%的空余，其中堆的总大小为536869376字节，空闲451978888字节，GC用去的总时间为78ms；
第三行：GC的三个阶段分别用去的是时间，其中标记（mark）阶段用了69ms，清除（sweep）阶段用了9ms，整理（compact）阶段用了0ms；
第四行：在此次GC中分别收集了多少个特殊的引用对象，其中收集的软（soft）引用对象0个，弱（weak）引用对象0个，虚（phantom）引用对象0个，以及由finalizer线程引用的对象329个。
使用方法跟踪，可跟踪方法的进入、退出、输入参数和返回值
-Dibm.dg.trc.print=mt 启动方法跟踪
-Dibm.dg.trc.methods 设置要跟踪的方法，例如：
-Dibm.dg.trc.methods=java/lang/String.* 跟踪String所有方法的进入和退出
-Dibm.dg.trc.methods=java/lang/String.*() 跟踪String所有方法的进入和退出，以及输入参数的值
-Dibm.dg.trc.methods=ArticleUI.*,!ArticleUI.get* 跟踪ArticleUI的所有方法，但不跟踪以get开头的方法
关于方法跟踪的更多信息，请查阅（[56] Chapter 28. Using method trace,[56] Chapter 33. TracingJava applications and the JVM）
JVM收到信号、堆空间不足或在程序中调用com.ibm.jvm.Dump.HeapDump()后都会生成heap dump。设置如下环境变量：
IBM_HEAPDUMP/IBM_HEAP_DUMP true # Enables heap dumps by means ofsignals.(Ctrl-/ on AIX or Linux,Ctrl-BREAK on Windows)
IBM_HEAPDUMPDIR <your_dump_dir> #heapdump存放目录
IBM_HEAPDUMP_OUTOFMEMORY true #在OutOfMemory时生成heapdump
关于堆转储的更多信息，请查阅（[56]Chapter 26. Using Heapdump）。
从IBM JDK1.5.0开始，可以使用dump agent来生成heap dump，例如：
-Xdump:heap:events=vmstop,opts=PHD+CLASSIC #表示在JVM停止时生成phd格式和txt格式的heapdump
-Xdump:heap:events=user,opts=PHD #表示JVM收到信号时生成heap dump
-Xdump:heap:events=throw,filter=java/lang/OutOfMem* #表示在OutOfMemory时生成heapdump
-Xdump:heap:none #表示关闭所有生成heap dump的操作
关于dump agent的更多信息，请查阅（[64] Chapter23. Using dump agents,[64] Chapter 25. Using Heapdump）。
严重的native错误，JVM收到信号，堆空间不足或在程序中调用com.ibm.jvm.Dump.JavaDump()后都会生成java dump。有用的环境变量设置：
DISABLE_JAVADUMP #禁用javadump，可设成任意值
IBM_JAVACOREDIR <your_dump_dir> #javadump存放目录
IBM_JAVADUMP_OUTOFMEMORY false #在OutOfMemory时不生成javadump
关于堆转储的更多信息，请查阅（[56]Chapter 25. Using Javadump）。
从IBM JDK1.5.0开始，可以使用dump agent来生成java dump，例如：
-Xdump:java:events=user #表示JVM收到信号时生成java dump
-Xdump:java:events=throw,filter=java/lang/OutOfMem* #表示在OutOfMemory时生成javadump
-Xdump:java:none #表示关闭所有生成javadump的操作
关于dump agent的更多信息，请查阅（[64]Chapter 23. Using dump agents,[64] Chapter 24. Using Javadump）。
5． WebSphere提供的方法和工具
使用WebSphere提供的wsadmin工具获得堆转储（heap dump）和线程转储（java dump）
wsadmin工具的路径：${WAS_HOME}/AppServer/bin/wsadmin.bat
在WebSphere6.1中使用IBM JDK 1.5，可以使用如下命令生成java dump和heap dump
生成heap dump的方法如下：
#查找 JVM objectName：
<wsadmin> set objectName [$AdminControlqueryNames WebSphere:type=JVM,process=<servername>,node=<nodename>,*]
#对 JVM MBean 调用generateHeapDump操作：
<wsadmin> $AdminControl invoke$objectName generateHeapDump
生成java dump的方法如下：
#查找 JVM objectName：
<wsadmin>set objectName[$AdminControl queryNames WebSphere:type=JVM,process=<servername>,node=<nodename>,*]
#对 JVM MBean调用dumpThreads操作：
<wsadmin> $AdminControl invoke$objectName dumpThreads
在WebSphere5.1和WebSphere6.0中，使用IBM JDK 1.4.2中，由于generateHeapDump不可用，可以使用如下命令生成java dump和heap dump
可以在"进程管理 ->进程定义 -> 环境条目"中添加以下属性：
IBM_HEAPDUMP true #Enables heap dumps by means of signals
IBM_HEAP_DUMP true # Enables heap dumps by means ofsignals
IBM_HEAPDUMPDIR <your_dump_dir> #heapdump存放目录
IBM_HEAPDUMP_OUTOFMEMORY true #在OutOfMemory时生成heapdump
IBM_JAVADUMP_OUTOFMEMORY true #在OutOfMemory时生成javadump
IBM_JAVA_HEAPDUMP_TEXT true # Enables heap dumps to be generatedin .txt format not in .phd format
生成heap dump的方法如下：
#查找 JVM objectName：
<wsadmin> set objectName [$AdminControlqueryNamesWebSphere:type=JVM,process=<servername>,node=<nodename>,*]
#对 JVM MBean 调用dumpThreads操作：
<wsadmin> $AdminControl invoke$objectName dumpThreads
生成java dump的方法如下：
#查找 JVM objectName：
<wsadmin> set objectName [$AdminControlqueryNamesWebSphere:type=JVM,process=<servername>,node=<nodename>,*]
按下Ctrl+Break
关于如何生成java dump和heap dump，请参考（[60]、[63）。
分析java dump的工具：IBM Thread and Monitor DumpAnalyzer for Java http://www.alphaworks.ibm.com/tech/jca
分析heap dump的工具：HeapAnalyzer http://www.alphaworks.ibm.com/tech/heapanalyzer
关于WebSphere的更多诊断工具的介绍，请参考（[61]）。
<!-- [if gte mso 9]><![endif]--><!-- [if gte mso 9]><![endif]--><!-- [if !mso]><!-- [if gte mso 10]>
WebSphere系统管理
[1]WebSphere Application Server V5系统管理:
第 1部分：V5 管理概览 http://www.ibm.com/developerworks/cn/websphere/techjournal/0301_williamson/williamson.html
第 2部分：编写您自己的管理程序 http://www.ibm.com/developerworks/cn/websphere/techjournal/0302_cundiff/cundiff.html
第 3部分：事件通知 http://www.ibm.com/developerworks/cn/websphere/techjournal/0304_lauzon/lauzon.html
第 4部分：如何扩展 WebSphere 管理系统 http://www.ibm.com/developerworks/cn/websphere/techjournal/0304_williamson/williamson.html
第 5部分：程序化配置 http://www.ibm.com/developerworks/cn/websphere/techjournal/0307_wang/wang.html
第 6部分：应用程序管理 http://www.ibm.com/developerworks/cn/websphere/techjournal/0309_apte/apte.html
[2]WebSphere管理资料 http://blog.chinaunix.net/u/473/showart_105062.html
[3]IBM WebSphere开发者技术期刊: WebSphere Application Server V5高级安全性和系统加固
http://www.ibm.com/developerworks/cn/websphere/techjournal/0406_botzum/0406_botzum.html
[4]IBM InfoCenter http://publib.boulder.ibm.com/infocenter/wasinfo/v5r1/index.jsp
[5] IBM WebSphere V5.0 Security WebSphere Handbook Series http://publib-b.boulder.ibm.com/abstracts/sg246573.html?Open
[6] WAS 5.x中数据源的配置使用及其常见问题 http://www.ibm.com/developerworks/cn/websphere/library/techarticles/fanggw/0406_was5ds/was5ds.html
[7] Understanding the WebSphere Application Server Web serverplug-in http://www.ibm.com/developerworks/websphere/library/techarticles/0310_cocasse/cocasse.html
[8] WebSphere应用服务器环境搭建实践指南 http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0707_wudan/
[9] WebSphere Application Server V6.1: System Management andConfiguration http://www.redbooks.ibm.com/abstracts/sg247304.html?Open
GC资料
[10]Reference Objects and Garbage Collection http://www.pawlan.com/Monica/refobjs/
[11]Java 2引用类使用指南 http://www.ibm.com/developerworks/cn/java/j-refs/
[12]Java理论与实践:用弱引用堵住内存泄漏 http://www.ibm.com/developerworks/cn/java/j-jtp11225/
[13]Java理论和实践:用软引用阻止内存泄漏 http://www.ibm.com/developerworks/cn/java/j-jtp01246.html
[14]垃圾收集器与Java编程 http://www.ibm.com/developerworks/cn/java/l-JavaMemoryLeak2/
SUN JVM资料
[20]关注性能:谈论垃圾 http://www.ibm.com/developerworks/cn/java/j-perf05214/
[21]关注性能:调优垃圾收集 http://www.ibm.com/developerworks/cn/java/j-perf06304/
[22]Java理论与实践:垃圾收集简史http://www.ibm.com/developerworks/cn/java/j-jtp10283/
[23]Java理论与实践:JVM 1.4.1中的垃圾收集 http://www.ibm.com/developerworks/cn/java/j-jtp11253/index.html
[24]Javatheory and practice: Garbage collection and performance
http://www.ibm.com/developerworks/java/library/j-jtp01274.html?S_TACT=105AGX52&S_CMP=cn-a-j
[25]TuningGarbage Collection with the 1_4_2 Java[tm] Virtual Machine http://java.sun.com/docs/hotspot/gc1.4.2/index.html
[26]TuningGarbage Collection with the 5.0 JavaTM Virtual Machine http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
[27]ImprovingJava Application Performance and Scalability by Reducing Garbage CollectionTimes and Sizing Memory
http://developers.sun.com/mobility/midp/articles/garbage/
[28]ImprovingJava Application Performance and Scalability by Reducing Garbage CollectionTimes and Sizing Memory Using JDK 1.4.1
http://developers.sun.com/mobility/midp/articles/garbagecollection2/
[29]JavaHotSpot VM Options http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp
[30]FrequentlyAsked Questions about Garbage Collection in the Hotspot[TM] Java[TM] VirtualMachine
http://java.sun.com/docs/hotspot/gc1.4.2/faq.html
[31]Turbo-charging Java HotSpot Virtual Machine, v1.4.x toImprove the Performance and Scalability of Application Servers
http://java.sun.com/developer/technicalArticles/Programming/turbo/
[32]jvmstat 3.0 http://java.sun.com/performance/jvmstat/
[33]jvmstat FAQ http://java.sun.com/performance/jvmstat/faq.html
[34]HPROF: A Heap/CPU Profiling Tool in J2SE 5.0 http://java.sun.com/developer/technicalArticles/Programming/HPROF.html
[35]Quick Troubleshooting Tips on Windows for Java SE 5.0 http://java.sun.com/javase/6/webnotes/trouble/other/matrix5-Windows.html
[36]Quick Troubleshooting Tips on Solaris OS and Linux for Java SE5.0 http://java.sun.com/javase/6/webnotes/trouble/other/matrix5-Unix.html
[37]PerfAnal: A Performance Analysis Tool http://java.sun.com/developer/technicalArticles/Programming/perfanal/index.html
[38]Using JConsole to Monitor Applications http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html
[39]Monitoring and Management Using JMX http://java.sun.com/j2se/1.5.0/docs/guide/management/agent.html
[40]Troubleshooting Guide for Java SE 6 with HotSpot VM http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/index.html
[41]Troubleshooting and Diagnostic Guide for JavaTM 2 Platform, StandardEdition 5.0http://java.sun.com/j2se/1.5/pdf/jdk50_ts_guide.pdf
IBM JVM资料
[50]IBMJDK 1.4.2的垃圾回收行为
（一） http://www-1.ibm.com/support/docview.wss?uid=csc1c4da5d7f9543bda44825717e00000759
（二） http://www-1.ibm.com/support/docview.wss?uid=csc1665d3ff3ebd54e0fc825719a0027c278
[51]优化 Java垃圾收集的性能 http://www.ibm.com/developerworks/cn/java/i-gctroub/
Fine-tuning Java garbagecollection performance http://www.ibm.com/developerworks/ibm/library/i-gctroub/?S_TACT=105AGX52&S_CMP=cn-a-j
[52]Mashthat trash -- Incremental compaction in the IBM JDK Garbage Collector
http://www.ibm.com/developerworks/ibm/library/i-incrcomp/?S_TACT=105AGX52&S_CMP=cn-a-j
[53]Sensible Sanitation -- Understanding the IBM Java GarbageCollector,
Part 1 Objectallocation http://www.ibm.com/developerworks/ibm/library/i-garbage1/
Part 2 Garbagecollection http://www.ibm.com/developerworks/ibm/library/i-garbage2/
Part 3 verbosegcand command-line parameters http://www.ibm.com/developerworks/library/i-garbage3.html
[54]Java 技术，IBM风格: 垃圾收集策略，第 1 部分 http://www.ibm.com/developerworks/cn/java/j-ibmjava2/
Java technology,IBM style: Garbage collection policies,
Part 1 http://www.ibm.com/developerworks/java/library/j-ibmjava2/
Part 2 http://www.ibm.com/developerworks/java/library/j-ibmjava3/
[55]如何在IBM JDK 1.4.2的环境中避免Java堆空间的碎片问题 http://www-900.ibm.com/cn/support/viewdoc/detail?DocId=2447476A10000
Avoiding Java heapfragmentation with V1_4_2
[56]IBM Developer Kit and Runtime Environment, Java 2Technology Edition, Version 1.4.2 Diagnostics Guide
http://www-128.ibm.com/developerworks/java/jdk/diagnosis/
[57]IBM的 Java诊断，
第 1部分: 介绍面向 Java 的 IBM转储分析器（IBM Dump Analyzer） http://www.ibm.com/developerworks/cn/java/j-ibmtools1/
第 2部分: 使用 Extensible Verbose Toolkit进行垃圾收集 http://www.ibm.com/developerworks/cn/java/j-ibmtools2/
第 3部分: 使用面向 Java 的 LockAnalyzer诊断同步和锁问题 http://www.ibm.com/developerworks/cn/java/j-ibmtools3/
第 4部分: 使用分析模块扩展 IBM Dump Analyzer for Java http://www.ibm.com/developerworks/cn/java/j-ibmtools4/
[58]WebSphere Application Server中的内存泄漏检测与分析:
第 1部分：内存泄漏概述 http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0606_poddar/0606_poddar.html
第 2部分：用于泄漏检测与分析的工具和功能 http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0608_poddar/0608_poddar.html
[59]Enabling verbose garbage collection (verbosegc) inWebSphere Application Server
http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg21114927
[60]Solving memory problems in WebSphere applications http://www.ibm.com/developerworks/websphere/library/techarticles/0706_sun/0706_sun.html
[61]The Support Authority: Choosing the right WebSpherediagnostic tool
http://www.ibm.com/developerworks/websphere/techjournal/0807_supauth/0807_supauth.html
[62]Preventing mark stack overflows during garbagecollection in the Java SDK
[63]IBM WebSphere V5.1 Performance, Scalability, and HighAvailability WebSphere Handbook Series
http://www.redbooks.ibm.com/abstracts/SG246198.html?Open
[64]IBM Developer Kit and Runtime Environment, JavaTechnology Edition, Version 5.0 Diagnostics Guide
http://www-128.ibm.com/developerworks/java/jdk/diagnosis/
[65]WebSphere Application Server V5.1 System Management andConfiguration WebSphere Handbook Series
http://www.redbooks.ibm.com/abstracts/sg246195.html?Open
[66]最大化 AIX上的 Java 性能
第 1部分: 基础 http://www.ibm.com/developerworks/cn/aix/library/es-Javaperf/es-Javaperf1.html
第 2部分: 速度需求 http://www.ibm.com/developerworks/cn/aix/library/es-Javaperf/es-Javaperf2.html
第 3部分: 更多就是更好 http://www.ibm.com/developerworks/cn/aix/library/es-Javaperf/es-Javaperf3.html#resources
第 4部分: 监视流量 http://www.ibm.com/developerworks/cn/aix/library/es-Javaperf/es-Javaperf4.html
第 5部分: 参考资料和结论 http://www.ibm.com/developerworks/cn/aix/library/es-Javaperf/es-Javaperf5.html
1085
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
