Jconsole简介：
Jconsole是一个JMX兼容的监视工具。它使用Java虚拟机的JMX机制来提供运行在Java平台的应用程序的性能与资源耗费信息。
监控进程使用方法如下：
由于JConsole监控需要使用JMX代理技术，因此在启动应用程序的参数中添加以下几个参数：
-Djava.rmi.server.hostname=192.168.1.80
-Dcom.sun.management.jmxremote.port=8089
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
配置完以上参数后，本地启动JConsole后，选择相应的进程名称，点击连接后，就可监控了。
关于JMX的介绍：
http://www.51testing.com/?uid-115295-action-viewspace-itemid-804845
其他使用：
Jconsole界面：
Jconsole界面由以下六个选项卡组成：
Summary选项卡：显示JVM和被监视值的汇总信息
Memory选项卡：显示内存使用信息。
Threads选项卡：显示线程使用信息。
Classes选项卡：显示类（class）加载信息。
MBeans选项卡：显示MBeans信息
VM选项卡：显示JVM信息。
以下是详细介绍：
查看汇总信息：
Summary选项卡显示了关于线程使用、内存消耗和class加载的一些关键监视信息，以及JVM和操作系统的信息。
Summary
Uptime：JVM已运行时长。
Total compile time：花费在即时编译（JIT compilation）中的时间。
Process CPU time：JVM花费的总CPU时间。
Threads
Live threads：当前活动的daemon线程加non-daemon线程数量。
Peak：自JVM启动后，活动线程峰值。
Daemon threads：当前活动的Daemon线程数量。
Total started：自JVM启动后，启动的线程总量（包括daemon,non-daemon和终止了的）
Memory
Current heap size：堆（heap）占用的内存量，以K为单位。
Committed memory：为堆分配的内存总量
Maximum heap size：堆占用的最大内存量。
Objects pending for finalization：等待析构（finalization）的对象数量。
Garbage collector information：GC信息，摆阔垃圾回收器名称，已执行的垃圾回收次数和执行垃圾回收总耗时。
Classes
Current classes loaded：当前被加载到内存的classes数量
Total classes loaded：自JVM启动后被加载到内存的classes总量，包括后来卸载的。
Total classes unloaded：自JVM启动后，从内存卸载的classes总量。
Operating System：
Total physical memory：物理内存总量
Free physical memory：物理内存空闲量
Committed virtual memory：为运行中的进程分配的虚拟内存总量
监视内存消耗：
Memory选项卡提供了内存消耗和内存池信息。
以上图表显示了JVM的内存使用和时间的对应关系，包括heap和non-heap内存以及指定的（specific）内存池。内存池种类与具体使用的JVM有关，以HotSpot JVM为例，内存池有：
l Eden Space（heap）：大多数对象初始化时从Eden Space池分配内存，即是存在于此池中
l Survivor Space（heap）：此池包含的对象是那些原先在eden space中，但是已经经历过垃圾回收而仍然存在的对象。
l Tenured Generation（heap）：在surviver space中已经存在了一段时间之后的对象会移动到这个池中。
l Permanent Generation（non-heap）：包含虚拟机自身的所有反射数据。比如class和mothod对象。对于使用classdatasharing的JVM，这一代分为只读和读写两个区域。
Code Cache （non-heap）：HotSpot JVM也包含一个“代码缓存”，是编译和存储本地代码所占用的内存。
查看关于内存池的详细信息：Garbage Collection.
Detail区域显示了几种当前内存度量：
lUsed：当前使用的内存总量。使用的内存总量是指所有的对象占用的内存，包括可达和不可达的对象。
lCommitted：JVM可使用的内存量。Committed内存数量可能随时间变化而变化。JAVA虚拟机可能将某些内存释放，还给操作系统，committed内存可能比启动时初始分配的内存量要少。Committed内存总是大于等于used内存。
lMax：内存管理可用的最大内存数量。此值可能改变或者为未定义。如果JVM试图增加使用内存（used memory）超出了committed内存，那么即时使用内存小于或者等于最大内存（比如系统虚拟内存较低），内存分配仍可能失败。
右下角的图表显示了内存池在heap和non-heap消耗的内存量。当内存使用超出了内存使用阀值时，柱状图会变红。你可以通过设置MemoryMXBean的一个属性来调整内存占用阀值。
Heap and Non-heap内存
JVM管理两种内存：heap和non-heap内存，两种内存都是在JVM启动时建立。
Heap memory是运行时数据区域，用于JVM为所有对象实例和队列分配的内存。Heap可能为固定植或者可变值。垃圾收集器是一个用于回收对象占用的heap内存的自动化内存管理系统。
Non-heap memory 包含一个在所有线程共享的方法区域（method area）和内部进程或JVM优化所需的内存。它存储了每一个类的结构，比如运行常量池，字段和方法数据，构造函数和方法的代码。方法区域逻辑上是 heap的一部分，但是依赖于实现，JVM可能不进行垃圾收集或压缩。像heap一样，方法区域可能为固定或可变大小。方法区域所需要的内存没有必要是连 续的。
除了方法区域之外，一个JVM实现的内部进程或优化所需的内存也属于non-heap内存。比如JIT编译器为了提高性能而用于存储本地机器码所需的内存。
内存池和内存管理
内存池（Memory pools）和内存管理器是JVM内存管理系统的关键部分
一个内存池（memory pool）代表JVM管理的一块内存区域。JVM拥有最少一个内存池，JVM在运行中可能创建或删除内存池。一个内存池可以属于heap内存或者non-heap内存。
内存管理器（memory manager）管理一个或多个内存池。垃圾回收其是一种负责回收被不可打对象占用的内存的内存管理器。一个JVM可以拥有一个或者多个内存管理器。JVM在运行中可能增加或删除内存管理器。一个内存池可以被多于一个内存管理器管理。
垃圾收集：
垃圾收集（GC）是指JVM释放那些被无引用对象占用的内存空间。它通常认为那些有活动引用的对象是“活”对象，而那些没有引用或不可达的对象为“死”对象”。垃圾收集是释放被死对象占用的内存的过程。GC的算法和参数对性能有巨大的影响。
HotSpot VM垃圾收集器使用 分代垃圾收集（generational garbage collection）。分代GC利用了大多数程序中，从经验看有如下特点：
很多对象有一个很短的生存期（比如迭代器iterators、本地变量）
某些对象拥有很长的生存期（比如高层持久化对象）
所 以，分代的GC将内存划分为代（generations）并且赋予每一个内存池。当一代用尽了分配的内存，VM会在那个内存池进行一次局部 （partial）的垃圾收集（或者叫minor collection）来收集被死对象占用的内存。局部垃圾收集比全垃圾收集（full GC）快的多。
HotSpot VM定义了2代：young generation （有时叫做nursery）和old generation。Young generation由一个eden space和两个survivor spaces组成。最初，VM将所有的对象放入eden space，大多数对象死在那里~~~，当VM运行了一次minor GC，VM将剩余的对象从eden space移动到某个survivor space中。然后VM将那些在survivor spaces中生存了足够长时间的对象移动到位于old generation中的tenured spaces。当tenured spaces满了以后，将发生一次full GC，full GC涉及到所有存活的对象，因此比较慢。Permanent generation保存了所有的虚拟机自身的反射数据，比如class和method objects
默认情况下代的排列类似于下图：
如同下文链接中说明的，如果垃圾收集器成为瓶颈，你可以通过自定义代大小来提高性能。使用jconsole可以发现你的性能情况对垃圾收集器参数的敏感程度。详细情况见：
Tuning Garbage collection with the 5.0 HotSpot VM
监视线程使用：
线程选项卡提供了关于线程使用的信息。
左下角列出的为所有的活动线程。如果你在过滤（filter）对话框输入字符串，那么线程列表将尽显示那些包含你输入字符串的线程。在线程列表上点击线程名，可以显示在右侧显示县城信息，包括线程名，状态和调用堆栈。
图表显示了活动线程/时间。有三行内容：
Magenta：线程总数
Red：峰值线程数
Blue：活动线程数。
关于线程、daemon线程详细信息，请查看链接：java.lang.Thread
监视Class加载：
Classes选项卡显示了关于class loading的信息：
图表显示了 类加载/时间
红线是类加载总数（包括后来卸载的）
蓝线表示当前的类加载数量。
选项卡底部的Detail节显示了自JVM启动后类加载的总量，当前加载量和卸载量。
监视和管理MBeans：
MBean选项卡显示了所有在platform. MBeanserver上注册的MBeans的信息。
左边的树形结构显示了所有的MBean，按其对象名排序。当在树种选择了一个MBean之后，其属性、操作、通知和其他信息会在右边显示。
如果属性值是可写的（可写会蓝色显示），你可以设置属性值。你也可以调用在操作选项卡中显示的操作。
显示图表：
你可以通过双击属性值的方法显示一个属性值/时间图表，比如，如果你双击java.lang.GarbageCollector.Copy Mbean的CollectionTime属性，你会得到如下图所示的显示：
查看VM信息。
VM选项卡提供了JVM的信息。
这些信息包括：
Uptime：JVM启动后的总时间。
Processes CPU Time：JVM启动后消耗的总CPU时间。
Total Compile Time：即时编译（JIT compilation）消耗的总时间。JVM的具体实现决定JIT编译何时发生。Hotspot VM使用adaptive compilation，在这种方式zhogn ，VM使用标准的解释器（interpreter）运行一个应用程序，但是会分析其代码判断性能瓶颈或者”hot spots”。
配置tomcat使用jconsole
修改catalina脚本
Windows平台：修改catalina.bat，在dorun和dostart段开头增加一行（注意是一行）：
set JAVA_OPTS=%JAVA_OPTS% -Djava.rmi.server.hostname=192.168.1.101
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port="9004"
-Dcom.sun.management.jmxremote.authenticate="false" -Dcom.sun.management.jmxremote.ssl="false"
Unix/Linux平台：修改catalina.sh，在dorun和dostart段开头增加一行（注意是一行）：
JAVA_OPTS="$JAVA_OPTS "-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port="9004"
-Dcom.sun.management.jmxremote.authenticate="false" -Dcom.sun.management.jmxremote.ssl="false"
启动jconsole
启动tomcat之后，根据上文中的jconsole简介中的命令启动jconsole，如果是在服务器本地运行jconsole，会出现如下界面：
直接进行连接即可。
如果是远程监控，需要点击远程选项卡并输入相关信息，示例如下：
“主机名或ip”处填写需要监视的主机ip，端口为服务器上上文中添加的-Dcom.sun.management.jmxremote.port="portNumber"设定的端口，本文以9004为例。在设定为：-Dcom.sun.management.jmxremote.authenticate="false" 的情况下，用户名和口令留空即可。
如果需要使用JConsole远程监控 Tomcat可以在命令行直接输入：
JConsole 192.168.1.101:9004
进阶安全设定
在上文中的配置适用于在测试环境中监视tomcat，如果是在生产环境中监视tomcat则需要在安全性上有进一步要求。
配置jmx访问密码
1． 修改上文中的catalina脚本中的JAVA_OPT参数，将
-Dcom.sun.management.jmxremote.authenticate="false" 修改为：
-Dcom.sun.management.jmxremote.authenticate="true"
2． 将$JRE/lib/management/jmxremote.password.template文件在同目录下复制一份，重命名为$JRE/lib /management/jmxremote.password，编辑jmxremote.password，添加允许访问的用户名及密码，比如添加用户 zxwh，密码为zxme，则在文件尾添加一行：
zxwh zxme
注意用户密码不能包含空格，tab等字符
3． 编辑$JRE_HOME/lib/management/jmxremote.access文件，对刚才添加的用户赋予一定的权限：
zxwh readonly （或者readwrite）
4． 确认jmxremote.password和jmxremote.access两个文件中的用户是相同的。注意如果jmxremote.access中没有对应用户的话，配置是无效的。
注：以上配置文件的位置都是可以更改的，具体配置方法在此不再赘述。
5． 由于jmxremote.password中的密码都是明文保存的，所以jmxremote.password、jmxremote.access文件的权限要注意，应该设置为只有owner才可读，当然这个用户也必须是启动tomcat的用户。
6． 启动jconsole进行连接，在用户名和口令处输入设定的用户和密码。
7． 使用密码认证方式进行连接，不但可以提高安全性，而且可以对用户的权限进行设置。如果不使用密码认证的方式，则无法对用户的权限进行限制。
配置使用ssl进行加密连接
1． 在服务器上使用keytool创建密钥对
keytool是java平台自带的一个密钥和证书管理工具，使用keytool创建密钥对：
keytool -genkey -alias tomcat -keystore /somepath/tomcatKeyStore
按照提示输入相关信息（包括设定密码、姓、组织名等），这些信息是可以随便输入的，但从产品角度讲应该统一设定。输入的密码在今后操作中均需要使用。
2． 导出公钥
keytool -export -alias tomcat -keystore /somepath/tomcatKeyStore -file /somepath/jconsole.cert
3． 将公钥导入至需要运行jconsole的机器。
keytool –import –alias jconsole –keystore /somepath/jconsoleKeyStore -file /somepath/jconsole.cert
4． 修改tomcat的catalina脚本
将-Dcom.sun.management.jmxremote.ssl="false"修改为：
-Dcom.sun.management.jmxremote.ssl="true"，并在 JAVA_OPTS变量行添加：
-Djavax.net.ssl.keyStore=/somepath/jconsoleKeyStore
-Djavax.net.ssl.keyStorePassword=设定的密码
5． 使用如下参数启动jconsole ：
jconsole -J-Djavax.net.ssl.trustStore=/somepath/jconsoleKeyStore
6． 填入主机名、用户、口令连接服务器。
其他问题
1． 在执行shutdown.sh或者shutdown.bat脚本关闭tomcat时出现如下错误，tomcat无法关闭：
错误: 代理抛出异常: java.rmi.server.ExportException: Port already in use: 9004;
nested exception is:
java.net.BindException: Address already in use: JVM_Bind