西安网站制作公司排,常州免费网站建站模板,传媒网站制作,绵阳东原建设工程有限公司网站转载自 jstack(查看线程)、jmap(查看内存)和jstat(性能分析)命令
1#xff0e;Jstack 1.1 jstack能得到运行java程序的java stack和native stack的信息。可以轻松得知当前线程的运行情况。如下图所示 注#xff1a;这个和thread dump是同样的结果。但是thread dump是用ki…转载自 jstack(查看线程)、jmap(查看内存)和jstat(性能分析)命令
1Jstack 1.1 jstack能得到运行java程序的java stack和native stack的信息。可以轻松得知当前线程的运行情况。如下图所示 注这个和thread dump是同样的结果。但是thread dump是用kill -3 pid命令还是服务器上面少用kill为妙 1.2 命名行格式 jstack [ option ] pid jstack [ option ] executable core jstack [ option ] [server-id]remote-hostname-or-IP 最常用的还是jstack pid 1.3 在thread dump中要留意下面几种状态 死锁Deadlock重点关注 等待资源Waiting on condition重点关注 • 等待获取监视器Waiting on monitor entry重点关注 阻塞Blocked重点关注 • 执行中Runnable • 暂停Suspended • 对象等待中Object.wait() 或 TIMED_WAITING • 停止Parked 下面有详细的例子讲这种分析大家参考原著 http://www.cnblogs.com/zhengyun_ustc/archive/2013/01/06/dumpanalysis.html 1.4 在thread dump中有几种线程的定义如下 线程名称 所属 解释说明 Attach Listener JVM Attach Listener 线程是负责接收到外部的命令而对该命令进行执行的并且吧结果返回给发送者。通常我们会用一些命令去要求jvm给我们一些反馈信息如java -version、jmap、jstack等等。 如果该线程在jvm启动的时候没有初始化那么则会在用户第一次执行jvm命令时得到启动。 Signal Dispatcher JVM 前面我们提到第一个Attach Listener线程的职责是接收外部jvm命令当命令接收成功后会交给signal dispather 线程去进行分发到各个不同的模块处理命令并且返回处理结果。 signal dispather线程也是在第一次接收外部jvm命令时进行初始化工作。 CompilerThread0 JVM 用来调用JITing实时编译装卸class 。 通常jvm会启动多个线程来处理这部分工作线程名称后面的数字也会累加例如CompilerThread1 Concurrent Mark-Sweep GC Thread JVM 并发标记清除垃圾回收器就是通常所说的CMS GC线程 该线程主要针对于老年代垃圾回收。ps启用该垃圾回收器需要在jvm启动参数中加上 -XX:UseConcMarkSweepGC DestroyJavaVM JVM 执行main()的线程在main执行完后调用JNI中的 jni_DestroyJavaVM() 方法唤起DestroyJavaVM 线程。 JVM在 Jboss 服务器启动之后就会唤起DestroyJavaVM线程处于等待状态等待其它线程java线程和native线程退出时通知它卸载JVM。线程退出时都会判断自己当前是否是整个JVM中最后一个非deamon线程如果是则通知DestroyJavaVM 线程卸载JVM。 ps 扩展一下 1.如果线程退出时判断自己不为最后一个非deamon线程那么调用thread-exit(false) 并在其中抛出thread_end事件jvm不退出。 2.如果线程退出时判断自己为最后一个非deamon线程那么调用before_exit() 方法抛出两个事件 事件1thread_end 线程结束事件、事件2VM的death事件。 然后调用thread-exit(true) 方法接下来把线程从active list卸下删除线程等等一系列工作执行完成后则通知正在等待的DestroyJavaVM 线程执行卸载JVM操作。 ContainerBackgroundProcessor 线程 JBOSS 它是一个守护线程, 在jboss服务器在启动的时候就初始化了,主要工作是定期去检查有没有Session过期.过期则清除. 参考http://liudeh-009.iteye.com/blog/1584876 Dispatcher-Thread-3 线程 Log4j Log4j具有异步打印日志的功能需要异步打印日志的Appender都需要注册到 AsyncAppender对象里面去由AsyncAppender进行监听决定何时触发日志打印操作。 AsyncAppender如果监听到它管辖范围内的Appender有打印日志的操作则给这个Appender生成一个相应的event并将该event保存在一个buffuer区域内。 Dispatcher-Thread-3线程负责判断这个event缓存区是否已经满了如果已经满了则将缓存区内的所有event分发到Appender容器里面去那些注册上来的Appender收到自己的event后则开始处理自己的日志打印工作。 Dispatcher-Thread-3线程是一个守护线程。 Finalizer线程 JVM 这个线程也是在main线程之后创建的其优先级为10主要用于在垃圾收集前调用对象的finalize()方法关于Finalizer线程的几点 1) 只有当开始一轮垃圾收集时才会开始调用finalize()方法因此并不是所有对象的finalize()方法都会被执行 2) 该线程也是daemon线程因此如果虚拟机中没有其他非daemon线程不管该线程有没有执行完finalize()方法JVM也会退出 3) JVM在垃圾收集时会将失去引用的对象包装成Finalizer对象Reference的实现并放入ReferenceQueue由Finalizer线程来处理最后将该Finalizer对象的引用置为null由垃圾收集器来回收 4) JVM为什么要单独用一个线程来执行finalize()方法呢如果JVM的垃圾收集线程自己来做很有可能由于在finalize()方法中误操作导致GC线程停止或不可控这对GC线程来说是一种灾难 Gang worker#0 JVM JVM 用于做新生代垃圾回收monir gc的一个线程。#号后面是线程编号例如Gang worker#1 GC Daemon JVM GC Daemon 线程是JVM为RMI提供远程分布式GC使用的GC Daemon线程里面会主动调用System.gc()方法对服务器进行Full GC。 其初衷是当 RMI 服务器返回一个对象到其客户机远程方法的调用方时其跟踪远程对象在客户机中的使用。当再没有更多的对客户机上远程对象的引用时或者如果引用的“租借”过期并且没有更新服务器将垃圾回收远程对象。 不过我们现在jvm启动参数都加上了-XX:DisableExplicitGC配置所以这个线程只有打酱油的份了。 IdleRemover JBOSS Jboss连接池有一个最小值 该线程每过一段时间都会被Jboss唤起用于检查和销毁连接池中空闲和无效的连接直到剩余的连接数小于等于它的最小值。 Java2D Disposer JVM 这个线程主要服务于awt的各个组件。 说起该线程的主要工作职责前需要先介绍一下Disposer类是干嘛的。 Disposer提供一个addRecord方法。 如果你想在一个对象被销毁前再做一些善后工作那么你可以调用Disposer#addRecord方法将这个对象和一个自定义的DisposerRecord接口实现类一起传入进去进行注册。 Disposer类会唤起“Java2D Disposer”线程该线程会扫描已注册的这些对象是否要被回收了如果是则调用该对象对应的DisposerRecord实现类里面的dispose方法。 Disposer实际上不限于在awt应用场景只是awt里面的很多组件需要访问很多操作系统资源所以这些组件在被回收时需要先释放这些资源。 InsttoolCacheScheduler_ QuartzSchedulerThread Quartz InsttoolCacheScheduler_QuartzSchedulerThread是Quartz的主线程它主要负责实时的获取下一个时间点要触发的触发器然后执行触发器相关联的作业 。 原理大致如下 Spring和Quartz结合使用的场景下Spring IOC容器初始化时会创建并初始化Quartz线程池TreadPool并启动它。刚启动时线程池中每个线程都处于等待状态等待外界给他分配Runnable持有作业对象的线程。 继而接着初始化并启动Quartz的主线程InsttoolCacheScheduler_QuartzSchedulerThread该线程自启动后就会处于等待状态。等待外界给出工作信号之后该主线程的run方法才实质上开始工作。run中会获取JobStore中下一次要触发的作业拿到之后会一直等待到该作业的真正触发时间然后将该作业包装成一个JobRunShell对象该对象实现了Runnable接口其实看是上面TreadPool中等待外界分配给他的Runnable然后将刚创建的JobRunShell交给线程池由线程池负责执行作业。 线程池收到Runnable后从线程池一个线程启动Runnable反射调用JobRunShell中的run方法run方法执行完成之后 TreadPool将该线程回收至空闲线程中。 InsttoolCacheScheduler_Worker-2 Quartz InsttoolCacheScheduler_Worker-2线程就是ThreadPool线程的一个简单实现它主要负责分配线程资源去执行 InsttoolCacheScheduler_QuartzSchedulerThread线程交给它的调度任务也就是JobRunShell。 JBossLifeThread Jboss Jboss主线程启动成功应用程序部署完毕之后将JBossLifeThread线程实例化并且startJBossLifeThread线程启动成功之后就处于等待状态以保持Jboss Java进程处于存活中。 所得比较通俗一点就是Jboss启动流程执行完毕之后为什么没有结束 就是因为有这个线程hold主了它。 牛b吧 JBoss System Threads(1)-1 Jboss 该线程是一个socket服务默认端口号为 1099。 主要用于接收外部naming serviceJboss JNDI请求。 JCA PoolFiller Jboss 该线程主要为JBoss内部提供连接池的托管。 简单介绍一下工作原理 Jboss内部凡是有远程连接需求的类都需要实现ManagedConnectionFactory接口例如需要做JDBC连接的 XAManagedConnectionFactory对象就实现了该接口。然后将XAManagedConnectionFactory对象还有其它信息一起包装到InternalManagedConnectionPool对象里面接着将InternalManagedConnectionPool交给PoolFiller对象里面的列队进行管理。 JCA PoolFiller线程会定期判断列队内是否有需要创建和管理的InternalManagedConnectionPool对象如果有的话则调用该对象的fillToMin方法 触发它去创建相应的远程连接并且将这个连接维护到它相应的连接池里面去。 JDWP Event Helper Thread JVM JDWP是通讯交互协议它定义了调试器和被调试程序之间传递信息的格式。它详细完整地定义了请求命令、回应数据和错误代码保证了前端和后端的JVMTI和JDI的通信通畅。 该线程主要负责将JDI事件映射成JVMTI信号以达到调试过程中操作JVM的目的。 JDWP Transport Listener: dt_socket JVM 该线程是一个Java Debugger的监听器线程负责受理客户端的debug请求。 通常我们习惯将它的监听端口设置为8787。 Low Memory Detector JVM 这个线程是负责对可使用内存进行检测如果发现可用内存低分配新的内存空间。 process reaper JVM 该线程负责去执行一个 OS 命令行的操作。 Reference Handler JVM JVM在创建main线程后就创建Reference Handler线程其优先级最高为10它主要用于处理引用对象本身软引用、弱引用、虚引用的垃圾回收问题 。 Surrogate Locker Thread (CMS) JVM 这个线程主要用于配合CMS垃圾回收器使用它是一个守护线程其主要负责处理GC过程中Java层的Reference指软引用、弱引用等等与jvm 内部层面的对象状态同步。 这里对它们的实现稍微做一下介绍这里拿 WeakHashMap做例子将一些关键点先列出来我们后面会将这些关键点全部串起来 1. 我们知道HashMap用Entry[]数组来存储数据的WeakHashMap也不例外, 内部有一个Entry[]数组。 2. WeakHashMap的Entry比较特殊它的继承体系结构为Entry-WeakReference-Reference 。 3. Reference 里面有一个全局锁对象Lock它也被称为pending_lock. 注意它是静态对象。 4. Reference 里面有一个静态变量pending。 5. Reference 里面有一个静态内部类ReferenceHandler的线程它在static块里面被初始化并且启动启动完成后处于wait状态它在一个Lock同步锁模块中等待。 6. 另外WeakHashMap里面还实例化了一个ReferenceQueue列队这个列队的作用后面会提到。 7. 上面关键点就介绍完毕了下面我们把他们串起来。 假设WeakHashMap对象里面已经保存了很多对象的引用。 JVM 在进行CMS GC的时候会创建一个ConcurrentMarkSweepThread简称CMST线程去进行GCConcurrentMarkSweepThread线程被创建的同时会创建一个SurrogateLockerThread简称SLT线程并且启动它SLT启动之后处于等待阶段。CMST开始GC时会发一个消息给SLT让它去获取Java层Reference对象的全局锁Lock。 直到CMS GC完毕之后JVM 会将WeakHashMap中所有被回收的对象所属的WeakReference容器对象放入到Reference 的pending属性当中每次GC完毕之后pending属性基本上都不会为null了然后通知SLT释放并且notify全局锁:Lock。此时激活了ReferenceHandler线程的run方法使其脱离wait状态开始工作了。ReferenceHandler这个线程会将pending中的所有WeakReference对象都移动到它们各自的列队当中比如当前这个WeakReference属于某个WeakHashMap对象那么它就会被放入相应的ReferenceQueue列队里面该列队是链表结构。 当我们下次从WeakHashMap对象里面get、put数据或者调用size方法的时候WeakHashMap就会将ReferenceQueue列队中的WeakReference依依poll出来去和Entry[]数据做比较如果发现相同的则说明这个Entry所保存的对象已经被GC掉了那么将Entry[]内的Entry对象剔除掉。 taskObjectTimerFactory JVM 顾名思义该线程就是用来执行任务的。 当我们把一个认为交给Timer对象并且告诉它执行时间周期时间后Timer就会将该任务放入任务列队并且通知taskObjectTimerFactory线程去处理任务taskObjectTimerFactory线程会将状态为取消的任务从任务列队中移除如果任务是非重复执行类型的则在执行完该任务后将它从任务列队中移除如果该任务是需要重复执行的则计算出它下一次执行的时间点。 VM Periodic Task Thread JVM 该线程是JVM周期性任务调度的线程它由WatcherThread创建是一个单例对象。 该线程在JVM内使用得比较频繁比如定期的内存监控、JVM运行状况监控还有我们经常需要去执行一些jstat 这类命令查看gc的情况如下 jstat -gcutil 23483 250 7 这个命令告诉jvm在控制台打印PID为23483的gc情况间隔250毫秒打印一次一共打印7次。 VM Thread JVM 这个线程就比较牛b了是jvm里面的线程母体根据hotspot源码vmThread.hpp里面的注释它是一个单例的对象最原始的线程会产生或触发所有其他的线程这个单个的VM线程是会被其他线程所使用来做一些VM操作如清扫垃圾等。 在 VMThread 的结构体里有一个VMOperationQueue列队所有的VM线程操作(vm_operation)都会被保存到这个列队当中VMThread 本身就是一个线程它的线程负责执行一个自轮询的loop函数(具体可以参考VMThread.cpp里面的void VMThread::loop()) 该loop函数从VMOperationQueue列队中按照优先级取出当前需要执行的操作对象(VM_Operation)并且调用VM_Operation-evaluate函数去执行该操作类型本身的业务逻辑。 psVM操作类型被定义在vm_operations.hpp文件内列举几个ThreadStop、ThreadDump、PrintThreads、GenCollectFull、GenCollectFullConcurrent、CMS_Initial_Mark、CMS_Final_Remark….. 有兴趣的同学可以自己去查看源文件。 (搬运自 http://blog.csdn.net/a43350860/article/details/8134234 感谢原著作者) 2Jmap 2.1 得到运行java程序的内存分配的详细情况。例如实例个数大小等 2.2 命名行格式 jmap [ option ] pid jmap [ option ] executable core jmap [ option ] [server-id]remote-hostname-or-IP -dump:[live,]formatb,filefilename 使用hprof二进制形式,输出jvm的heap内容到文件. live子选项是可选的假如指定live选项,那么只输出活的对象到文件. -finalizerinfo 打印正等候回收的对象的信息. -heap 打印heap的概要信息GC使用的算法heap的配置及wise heap的使用情况. -histo[:live] 打印每个class的实例数目,内存占用,类全名信息. VM的内部类名字开头会加上前缀”*”. 如果live子参数加上后,只统计活的对象数量. -permstat 打印classload和jvm heap长久层的信息. 包含每个classloader的名字,活泼性,地址,父classloader和加载的class数量. 另外,内部String的数量和占用内存数也会打印出来. -F 强迫.在pid没有相应的时候使用-dump或者-histo参数. 在这个模式下,live子参数无效. -h | -help 打印辅助信息 -J 传递参数给jmap启动的jvm. 2.3 使用例子 jmap -histo pid(查看实例) jmap -dump:formatb,fileheap.bin pid(导出内存据说对性能有影响小心使用) (formatb是通过二进制的意思但是能不能导出文本文件我没找到知道的告诉我) 把内存结构全部dump到二进制文件中通过IBM的HeapAnalyzer和eclipse的MemoryAnalyzer都可以分析内存结构。 这个是我用HeapAnalyzer查看出的我们daily的内存结构已经列出了可能存在的问题。(这个工具我不熟悉只供大家参考) 下面是我用eclipse 的MemoryAnalyzer查看内存结构图 上面的是eclipse分析内存泄漏分析出的。这个功能点非常多。可以慢慢学习 3Jstat 3.1 这是一个比较实用的一个命令可以观察到classloadercompilergc相关信息。可以时时监控资源和性能 3.2 命令格式 -class统计class loader行为信息 -compile统计编译行为信息 -gc统计jdk gc时heap信息 -gccapacity统计不同的generations不知道怎么翻译好包括新生区老年区permanent区相应的heap容量情况 -gccause统计gc的情况同-gcutil和引起gc的事件 -gcnew统计gc时新生代的情况 -gcnewcapacity统计gc时新生代heap容量 -gcold统计gc时老年区的情况 -gcoldcapacity统计gc时老年区heap容量 -gcpermcapacity统计gc时permanent区heap容量 -gcutil统计gc时heap情况 3.3 输出参数内容 S0 — Heap上的 Survivor space 0 区已使用空间的百分比 S0CS0当前容量的大小 S0US0已经使用的大小 S1 — Heap上的 Survivor space 1 区已使用空间的百分比 S1CS1当前容量的大小 S1US1已经使用的大小 E — Heap上的 Eden space 区已使用空间的百分比 ECEden space当前容量的大小 EUEden space已经使用的大小 O — Heap上的 Old space 区已使用空间的百分比 OCOld space当前容量的大小 OUOld space已经使用的大小 P — Perm space 区已使用空间的百分比 OCPerm space当前容量的大小 OUPerm space已经使用的大小 YGC — 从应用程序启动到采样时发生 Young GC 的次数 YGCT– 从应用程序启动到采样时 Young GC 所用的时间(单位秒) FGC — 从应用程序启动到采样时发生 Full GC 的次数 FGCT– 从应用程序启动到采样时 Full GC 所用的时间(单位秒) GCT — 从应用程序启动到采样时用于垃圾回收的总时间(单位秒)它的值等于YGCFGC 例子1 例子2(连续5次) 例子3(PGCMN显示的是最小perm的内存使用量PGCMX显示的是perm的内存最大使用量PGC是当前新生成的perm内存占用量PC是但前perm内存占用量) 这个工具的参数非常多据说基本能覆盖jprofile等收费工具的所有功能了。多用用对于系统调优还是很有帮助的 注1我们在daily用这样命令时都要用-F参数的。因为我们的用户都不是启动命令的用户 注2daily的这些命令好像都没有配置到环境变量里面这个是我在自己应用机器里面看到的。需要去jdk目录底下执行。Sudo当然是必须的了
