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
阿萨德发是否
