java系统性能分析

netstat -ano | findstr 31900

 

注意最后是pid

堆栈的做用：

　线程死锁分析
　辅助CPU太高分析
　线程资源不足分析
　性能瓶颈分析
　关键线程异常退出

Windows：在运行java的控制台上按ctrl+break组合键 _ usefull?

wait() —— 会释放监视锁
sleep() —— 与锁操做无关,继续保持监视锁

Found one Java-level deadlock:

 

第三步：预处理前两个获取的堆栈信息，去掉处于sleeping或waiting的状态的线程。
例如以下线程处于wait或者sleep状态，
这种线程是不消耗CPU的，所以这些线程能够直接忽略掉，重点关注其它线程：

第五步：对比预处理后的1，2堆栈信息，找出处于busy状态的线程，该类线程多是致使cpu高占用率的可疑线程。
例如

同一个线程在第二个堆栈信息中仍处于活跃状态

两次打印堆栈该线程一直在运行，说明该线程已运行了5分钟，请在代码中检查该线程是否属于长时间运行线程？若是属于暂态线程，如此长时间运行说明可能有死循环等致使的CPU太高

常见架构和设计问题：
不恰当的线程同步
不良的架构（同步／异步使用不当）
并发设计不当－资源抢占致使的资源竞争, 链接池和线程池等应用不当等
效率低下的通讯方式
数据库链接等竞争资源参数设置不当
内存泄漏/不恰当的虚拟机运行参数
缓慢的磁盘/网络 IO

… …
常见编码问题
String +，getByte()的不恰当使用：不少时侯可使用StringBuf
过大的同步范围
ＳＱＬ语句设计不当

可以发现的性能问题：
(1) 资源争用
(2) 锁的粒度过大
(3) sleep的滥用

适用场合：
识别只有在高负载的时候才出现的性能瓶颈。
多线程场合

不适用的场合：
单操做单线程下的代码段耗时分析,如一次界面点击，感受迟缓。

方法：　Java 命令行中增长 –verbose:gc 运行参数

能够调节的JVM 垃圾回收参数
IBM JDK：主要参数： -Xconcurrentbackground –Xconcurrentlevel, 以及堆大小。
SUN，HP JDK 主要是 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction

.
常见的内存泄露
（1） 全局HashMap等容器，在对象不须要后没有及时从容器中remove掉
特别是在抛出异常的时候，必定要确保remove方法执行到。

（2） Runnable对象new了就必须使用线程来Run等

 

?? 能够按照以下思路分析GC输出,可以初步比较准确地判断系统是否存在内存泄漏:
?? (1) 首先要确保系统已经稳定运行(如初使化等已经完成等) (这个条件很重要)
?? (2) 而后取一个时间段的GC 输出做为分析数据，只分析FULL GC的行，以垃圾回收后的值为分析对象
?? (3) 而后根据GC分析内存的使用状况:
?????? A. 若是当前使用内存持续增加, 而垃圾回收后内存也持续增加, 有一直增加到Xmx设置的内存的趋势,
那么这个时侯基本上就能够判定有内存泄漏问题了.
?????? B. 若是当前使用内存增加到一个值以后,又能回落, 达到一个动态平衡, 那么就没有内存泄漏的状况.

 

（1） 只有FULL GC的行才有分析价值
（2） 只须要检查彻底垃圾后剩余的内存值是否一直再增大。

OptimizeIt
snoop抓包工具/ethereal

 阿萨德发是否