业界有很多功能强大的Java配置文件工具，包括Jporfiler和yourkit。 我不想说这些收费的东西。 我想说的是，其实java自己提供了很多内存监控小工具。 下面列举的工具只是一部分，仔细研究一下jdk的工具会很有趣：)
1:gc日志输出
将- xx :打印GC添加到jvm启动参数中
- xx :打印队列深度- xx :打印队列
- xx : printgcapplicationstopedtime，jvm按照这些参数顺序根据gc配置文件信息、详细信息、gc时间信息和gc
的适用暂停时间。 在刚才的参数之后添加参数-Xloggc:文件路径时，gc信息将输出到指定的文件。 其他参数是
-verbose:gc和- xx : printtenuringdistribution等。
2 :日本控制台
jconsole是jdk附带的内存分析工具，提供图形界面。 可以查看被监视的jvm的内存信息、线程信息、类加载信息和MBean信息。
控制台位于jdk目录下的mldh目录中，在windows上为jconsole.exe，在unix和linux上为
jconsole.sh，jconsole可以监视本地APP，也可以监视远程APP。 要监视本地APP应用程序，请运行jconsole
pid，pid是正在运行的java进程id。如果没有pid参数，则运行jconsole命令将弹出一个对话框，其中列出本地java订阅源
路线，可以选择一个进行监视。 如果要远程监视，则必须向远程服务器的jvm参数中添加一些内容。 关于，因为jconsole的远程监视是基于jmx的
有关jconsole的详细使用方法，请参阅专门介绍jconsle的文章。 我也在博客上专门详细介绍jconsole。
3:jviusalvm
在jdk更新7之后，jdk发布了另一个工具：jvisualvm、java可视化虚拟机。 JDK不仅提供与jconsole相同的功能，还提供jvm内存和cpu的实时诊断，手动dump JVM内存状态，手动运行gc。
与jconsole一样，运行jviusalvm并在jdk的mldh目录下运行jviusalvm，在windows下运行jviusalvm.exe，以及在linux和unix下运行jviusalvm.sh。
4:jmap
jmap是jdk附带的jvm内存分析工具，位于jdk的mldh目录中。 如何在jdk1.6中使用jmap命令：
Html代码
Usage:
jmap-histo (互联互通处理sandprinthistogramofjavaobjectheap
jmap-dump : (toconnecttorunningprocessanddumpjavaheap )。
dump-options 3360格式=bmldharydefaultfile=
dumpheapto
example : jmap-dump : format=b，file=heap.mldh
jmap -histo在画面上显示指定pid的jvm内存状况。 以本机为例，运行此命令后，画面显示如下。
Html代码
1:242062791864
2:223712145216[c]
3:242061940648
4:19511364496
5:265431282560
6:63771081744[b]
7:1793909688
8:1471614624
9336014581548336 [ ljava.lang.object；
10:3863513640[I]
1:20677496248 Java.lang.string
1:3621312776 [ ljava.util.hashmap $ entry；
13:335266800 Java.lang.reflect.method
1:8256264192 Java.io.objectstreamclass
$WeakClassKey15: 7066 226112 java.util.TreeMap$Entry
16: 2355 173304 [S
17: 1687 161952 java.lang.Class
18: 2769 150112 [[I
19: 3563 142520 java.util.HashMap
20: 5562 133488 java.util.HashMap$Entry
Total 239019 17140408
为了方便查看，我删掉了一些行。从上面的信息很容易看出，#instance指的是对象数量，#bytes指的是这些对象占用的内存大小，class name指的是对象类型。
再看jmap的dump选项，这个选项是将jvm的堆中内存信息输出到一个文件中，在我本机执行
jmap -dump:file=c:dump.txt 340
注意340是我本机的java进程pid，dump出来的文件比较
大有10几M，而且我只是开了tomcat，跑了一个很简单的应用，且没有任何访问，可以想象，大型繁忙的服务器上，dump出来的文件该有多大。需要知
道的是，dump出来的文件信息是很原始的，绝不适合人直接观看，而jmap
-histo显示的内容又太简单，例如只显示某些类型的对象占用多大内存，以及这些对象的数量，但是没有更详细的信息，例如这些对象分别是由谁创建的。那
这么说，dump出来的文件有什么用呢？当然有用，因为有专门分析jvm的内存dump文件的工具。
5：jhat
上面说了，有很多工具都能分析jvm的内存dump文件，jhat就是sun jdk6及以上版本自带的工具，位于jdk的mldh目录，执行 jhat
-J -Xmx512m
[file] ，file就是dump文件路径。jhat内置一个简单的web服务器，此命令执行后，jhat在命令行里显示分析结果的访问地址，可以用
-port选项指定端口，具体用法可以执行jhat -heap查看帮助信息。访问指定地址后，就能看到页面上显示的信息，比jmap
-histo命令显示的丰富得多，更为详细。
6：eclipse内存分析器
上面说了jhat，它能分析jvm的dump文件，但是全部是文字显示，eclipse memory analyzer，是一个eclipse提供用于分析jvm 堆dump的插件，网址为
http://www.eclipse.org/mat
,它的分析速度比jhat快，分析结果是图形界面显示，比jhat的可读性更高。其实jvisualvm也可以分析dump文件，也是有图形界面显示的。
7：jstat
如果说jmap倾向于分析jvm内存中对象信息的话，那么jsta就是倾向于分析jvm内存的gc情况。都是jvm内存分析工具，但显然，它们是从不同维
度来分析的。jsat常用的参数有很多，如
-gc,-gcutil,-gccause，这些选项具体作用可查看jsat帮助信息，我经常用-gcutil，这个参数的作用不断的显示当前指定的
jvm内存的垃圾收集的信息。
我在本机执行 jstat -gcutil 340
10000，这个命令是每个10秒钟输出一次jvm的gc信息，10000指的是间隔时间为10000毫秒。屏幕上显示如下信息(我只取了第一行，因为是
按的一定频率显示，所以实际执行的时候，会有很多行)：
S0 S1 E O P YGC YGCT FGC FGCT GCT
54.62 0.00 42.87 43.52 86.24 1792 5.093 33 7.670 12.763
额。。。怎么说呢，要看懂这些信息代表什么意思，还必须对jvm的gc机制有一定的了解才行啊。其实如果对sun的 hot spot
jvm的gc比较了解的人，应该很容易看懂这些信息，但是不清楚gc机制的人，有点莫名其妙，所以在这里我还是先讲讲sun的jvm的gc机制吧。说到
gc，其实不仅仅只是java的概念，其实在java之前，就有很多语言有gc的概念了，gc嘛就是垃圾收集的意思，更多的是一种算法性的东西，而跟具体
语言没太大关系，所以关于gc的历史，gc的主流算法我就不讲了，那扯得太远了，扯得太远了就是扯淡。sun现在的jvm，内存的管理模型是分代模型，所
以gc当然是分代收集了。分代是什么意思呢？就是将对象按照生命周期分成三个层次，分别是：zsdfh代，旧生代，持久代。对象刚开始分配的时候，大部分都在新
生代，当zsdfh代gc提交被触发后了，执行一次zsdfh代范围内的gc，这叫minor gc，如果执行了几次minor
gc后，还有对象存活，将这些对象转入旧生代，因为这些对象已经经过了组织的重重考验了哇。旧生代的gc频率会更低一些，如果旧生代执行了gc，那就是
full
gc，因为不是局部gc，而是全内存范围的gc，这会造成应用停顿，因为全内存收集，必须封锁内存，不许有新的对象分配到内存，持久代就是一些jvm期
间，基本不会消失的对象，例如class的定义，jvm方法区信息，例如静态块。需要主要的是，zsdfh代里又分了三个空
间：eden，susvivor0，susvivor1，按字面上来理解，就是伊甸园区，幸存1区，幸存2区。新对象分配在eden区中，eden区满
时，采用标记-复制算法，即检查出eden区存活
的对象，并将这些对象复制到是s0或s1中，然后清空eden区。jvm的gc说开来，不只是这么简单，例如还有串行收集，并行收集，并发收集，还有著名
的火车算法，不过那说得太远了，现在对这个有大致了解就好。说到这里，再来看一下上面输出的信息：
S0 S1 E O P YGC YGCT FGC FGCT GCT
54.62 0.00 42.87 43.52 86.24 1792 5.093 33 7.670 12.763
S0:zsdfh代的susvivor0区，空间使用率为54..62%
S1:zsdfh代的susvivor1区，空间使用率为0.00%(因为还没有执行第二次minor收集)
E:eden区，空间使用率42.87%
O:旧生代，空间使用率43.52%
P:持久带，空间使用率86.24%
YGC:minor gc执行次数1792次
YGCT:minor gc耗费的时间5.093毫秒
FGC:full gc执行次数33
FGCT:full gc耗费的时间7.670毫秒
GCT:gc耗费的总时间12.763毫秒
怎样选择工具
上面列举的一些工具，各有利弊，其实如果在开发环境，使用什么样的工具是无所谓的，只要能得到结果就好。但是在生产环境里，却不能乱选择，因为这些工具本
身就会耗费大量的系统资源，如果在一个生产服务器压力很大的时候，贸然执行这些工具，可能会造成很意外的情况。最好不要在服务器本机监控，远程监控会比较
好一些，但是如果要远程监控，服务器端的启动脚本要加入一些jvm参数，例如用jconsloe远程监控tomcat或jboss等，都需要设置jvm的
jmx参数，如果仅仅只是分析服务器的内存分配和gc信息，强烈推荐，先用jmap导出服务器端的jvm的堆dump文件，然后再用jhat，或者
jvisualvm，或者eclipse内存分析器来分析内存状况。