《jstack(查看线程)、jmap(查看内存)和jstat(性能分析)命令》由会员分享，可在线阅读，更多相关《jstack(查看线程)、jmap(查看内存)和jstat(性能分析)命令（7页珍藏版）》请在金锄头文库上搜索。
1、周末看到一个用 jstack 查看死锁的例子。昨天晚上总结了一下 jstack(查看线程)、jmap(查看内存)和 jstat(性能分析)命令。供大家参考1 Jstack1.1 jstack 能得到运行 java 程序的 java stack 和 native stack 的信息。可以轻松得知当前线程的运行情况。如下图所示注：这个和 thread dump 是同样的结果。但是 thread dump 是用 kill -3 pid 命令，还是服务器上面少用 kill 为妙1.2 命名行格式jstack option pidjstack option executable corejstack o
2、ption server-idremote-hostname-or-IP最常用的还是 jstack pid1.3 在 thread dump 中，要留意下面几种状态死锁，Deadlock（重点关注）等待资源，Waiting on condition（重点关注） 等待获取监视器，Waiting on monitor entry（重点关注）阻塞，Blocked（重点关注） 执行中，Runnable 暂停，Suspended 对象等待中，Object.wait() 或 TIMED_WAITING 停止，Parked下面有详细的例子讲这种分析，大家参考原著http:/ 在 thread dump 中，
3、有几种线程的定义如下线程名称 所属 解释说明Attach Listener JVM Attach Listener 线程是负责接收到外部的命令，而对该命令进行执行的并且吧结果返回给发送者。通常我们会用一些命令去要求 jvm 给我们一些反馈信息，如：java -version、jmap、jstack 等等。 如果该线程在 jvm 启动的时候没有初始化，那么，则会在用户第一次执行 jvm 命令时，得到启动。Signal Dispatcher JVM 前面我们提到第一个 Attach Listener 线程的职责是接收外部 jvm 命令，当命令接收成功后，会交给 signal dispather 线
4、程去进行分发到各个不同的模块处理命令，并且返回处理结果。 signal dispather 线程也是在第一次接收外部 jvm 命令时，进行初始化工作。CompilerThread0 JVM 用来调用 JITing，实时编译装卸 class 。 通常，jvm 会启动多个线程来处理这部分工作，线程名称后面的数字也会累加，例如：CompilerThread1Concurrent Mark-Sweep GC Thread JVM 并发标记清除垃圾回收器（就是通常所说的 CMS GC）线程， 该线程主要针对于老年代垃圾回收。ps：启用该垃圾回收器，需要在 jvm 启动参数中加上： -XX:+UseCon
5、cMarkSweepGCDestroyJavaVM JVM 执行 main()的线程在 main 执行完后调用 JNI 中的 jni_DestroyJavaVM() 方法唤起 DestroyJavaVM 线程。 JVM 在 Jboss 服务器启动之后，就会唤起DestroyJavaVM 线程，处于等待状态，等待其它线程（java 线程和 native 线程）退出时通知它卸载 JVM。线程退出时，都会判断自己当前是否是整个 JVM 中最后一个非 deamon 线程，如果是，则通知 DestroyJavaVM 线程卸载 JVM。ps：扩展一下：1.如果线程退出时判断自己不为最后一个非 deamon
6、 线程，那么调用 thread-exit(false) ，并在其中抛出 thread_end 事件，jvm 不退出。2.如果线程退出时判断自己为最后一个非 deamon 线程，那么调用 before_exit() 方法，抛出两个事件： 事件 1：thread_end 线程结束事件、事件 2：VM 的 death 事件。然后调用 thread-exit(true) 方法，接下来把线程从 active list 卸下，删除线程等等一系列工作执行完成后，则通知正在等待的 DestroyJavaVM 线程执行卸载 JVM 操作。ContainerBackgroundProcessor 线程 JBOSS
7、 它是一个守护线程, 在 jboss 服务器在启动的时候就初始化了,主要工作是定期去检查有没有 Session 过期.过期则清除.参考：http:/liudeh- 线程 Log4j Log4j 具有异步打印日志的功能，需要异步打印日志的 Appender 都需要注册到 AsyncAppender 对象里面去，由 AsyncAppender 进行监听，决定何时触发日志打印操作。 AsyncAppender 如果监听到它管辖范围内的 Appender 有打印日志的操作，则给这个 Appender 生成一个相应的 event，并将该 event 保存在一个buffuer 区域内。 Dispatche
8、r-Thread-3 线程负责判断这个 event 缓存区是否已经满了，如果已经满了，则将缓存区内的所有 event 分发到 Appender 容器里面去，那些注册上来的Appender 收到自己的 event 后，则开始处理自己的日志打印工作。 Dispatcher-Thread-3 线程是一个守护线程。Finalizer 线程 JVM 这个线程也是在 main 线程之后创建的，其优先级为 10，主要用于在垃圾收集前，调用对象的 finalize()方法；关于 Finalizer 线程的几点：1) 只有当开始一轮垃圾收集时，才会开始调用 finalize()方法；因此并不是所有对象的fina
9、lize()方法都会被执行；2) 该线程也是 daemon 线程，因此如果虚拟机中没有其他非 daemon 线程，不管该线程有没有执行完 finalize()方法，JVM 也会退出；3) JVM 在垃圾收集时会将失去引用的对象包装成 Finalizer 对象（Reference 的实现） ，并放入 ReferenceQueue，由 Finalizer 线程来处理；最后将该 Finalizer 对象的引用置为 null，由垃圾收集器来回收；4) JVM 为什么要单独用一个线程来执行 finalize()方法呢？如果 JVM 的垃圾收集线程自己来做，很有可能由于在 finalize()方法中误操作
10、导致 GC 线程停止或不可控，这对 GC 线程来说是一种灾难；Gang worker#0 JVM JVM 用于做新生代垃圾回收（monir gc）的一个线程。#号后面是线程编号，例如：Gang worker#1GC Daemon JVM GC Daemon 线程是 JVM 为 RMI 提供远程分布式 GC 使用的，GC Daemon 线程里面会主动调用 System.gc()方法，对服务器进行 Full GC。 其初衷是当 RMI 服务器返回一个对象到其客户机（远程方法的调用方）时，其跟踪远程对象在客户机中的使用。当再没有更多的对客户机上远程对象的引用时，或者如果引用的“租借”过期并且没有更新
11、，服务器将垃圾回收远程对象。不过，我们现在 jvm 启动参数都加上了-XX:+DisableExplicitGC 配置，所以，这个线程只有打酱油的份了。IdleRemover JBOSS Jboss 连接池有一个最小值， 该线程每过一段时间都会被 Jboss 唤起，用于检查和销毁连接池中空闲和无效的连接，直到剩余的连接数小于等于它的最小值。Java2D Disposer JVM 这个线程主要服务于 awt 的各个组件。 说起该线程的主要工作职责前，需要先介绍一下 Disposer 类是干嘛的。 Disposer 提供一个 addRecord 方法。如果你想在一个对象被销毁前再做一些善后工作，那
12、么，你可以调用 Disposer#addRecord方法，将这个对象和一个自定义的 DisposerRecord 接口实现类，一起传入进去，进行注册。Disposer 类会唤起“Java2D Disposer”线程，该线程会扫描已注册的这些对象是否要被回收了，如果是，则调用该对象对应的 DisposerRecord 实现类里面的 dispose 方法。Disposer 实际上不限于在 awt 应用场景，只是 awt 里面的很多组件需要访问很多操作系统资源，所以，这些组件在被回收时，需要先释放这些资源。InsttoolCacheScheduler_QuartzSchedulerThread Qu
13、artz InsttoolCacheScheduler_QuartzSchedulerThread 是Quartz 的主线程，它主要负责实时的获取下一个时间点要触发的触发器，然后执行触发器相关联的作业 。原理大致如下：Spring 和 Quartz 结合使用的场景下，Spring IOC 容器初始化时会创建并初始化Quartz 线程池（TreadPool） ，并启动它。刚启动时线程池中每个线程都处于等待状态，等待外界给他分配 Runnable（持有作业对象的线程） 。继而接着初始化并启动 Quartz 的主线程（InsttoolCacheScheduler_QuartzSchedulerThr
14、ead） ，该线程自启动后就会处于等待状态。等待外界给出工作信号之后，该主线程的 run 方法才实质上开始工作。run 中会获取 JobStore中下一次要触发的作业，拿到之后会一直等待到该作业的真正触发时间，然后将该作业包装成一个 JobRunShell 对象（该对象实现了 Runnable 接口，其实看是上面 TreadPool 中等待外界分配给他的 Runnable） ，然后将刚创建的 JobRunShell 交给线程池，由线程池负责执行作业。线程池收到 Runnable 后，从线程池一个线程启动 Runnable，反射调用 JobRunShell 中的 run方法，run 方法执行完成
15、之后， TreadPool 将该线程回收至空闲线程中。InsttoolCacheScheduler_Worker-2 Quartz InsttoolCacheScheduler_Worker-2 线程就是ThreadPool 线程的一个简单实现，它主要负责分配线程资源去执行InsttoolCacheScheduler_QuartzSchedulerThread 线程交给它的调度任务（也就是JobRunShell） 。JBossLifeThread Jboss Jboss 主线程启动成功，应用程序部署完毕之后将JBossLifeThread 线程实例化并且 start，JBossLifeThread 线程启动成功之后就处于等待状态，以保持 Jboss Java 进程处于存活中。 所得比较通俗一点，就是 Jboss 启动流程执行完毕之后，为什么没有结束？ 就是因为有这个线程 hold 主了它。 牛 b 吧JBoss System Threads(1)-1 Jboss 该线程是一个 socket 服务，默认端口号为： 1099。 主要用于接收外部 naming service（Jboss JNDI）请求。JCA PoolFiller Jboss 该线程主要为 JBoss 内部提供连接池的托管。 简单介绍一下工作原理 ：Jboss 内部凡是有远程连接需求的类，都需
