陕西的网站建设公司哪家好,金融类网站设计欣赏,公司建网站多少钱qcjxkd,网站建设方案的含义线程状态的解读RUNNABLE线程处于运行状态#xff0c;不一定消耗CPU。例如#xff0c;线程从网络读取数据#xff0c;大多数时间是挂起的#xff0c;只有数据到达时才会重新唤起进入执行状态。只有Java代码显式调用sleep或wait方法时#xff0c;虚拟机才可以精准获取到线程…线程状态的解读RUNNABLE线程处于运行状态不一定消耗CPU。例如线程从网络读取数据大多数时间是挂起的只有数据到达时才会重新唤起进入执行状态。只有Java代码显式调用sleep或wait方法时虚拟机才可以精准获取到线程真正的状态。调用本地方法时无法抓取本地代码的内部执行状态。TIME_WAITING(on object monitor)线程被挂起一段时间正在执行obj.wait(int time)的方法。不消耗CPU。TIME_WAITING(sleeping)线程被挂起一段时间正在执行Thread.sleep(int time)的方法。不消耗CPU。TIME_WAITING(parking)线程被挂起一段时间正在执行lock()的方法。不消耗CPU。WAINTING(on object monitor)线程被挂起执行执行obj.wait()的方法只能通过notify或notifyAll方法唤醒。不消耗CPU。死循环代码排查如果两次间隔时间打出来的堆栈排除掉wait和sleep状态的线程存在相同的线程操作。需要怀疑是不是有死循环代码存在。1使用了线程不安全的集合类HashMap在多线程读写场景主要指的jdk1.7及其以前。详细分析可见这篇文章https://blog.csdn.net/m0_46405589/article/details/1092064322对共享变量没有做保护3其他借助top命令输入1看到每个核的cpu使用率CPU使用率异常代码排查可能原因Java代码中存在死循环代码JNI代码中存在死循环代码堆内存过小导致频繁的GC在32位JDK中由于堆内存设置过大造成的频繁GC系统不合理的设计如不间断的轮循操作JDK源码的死循环bug分析手段top -p 进程号输入H查看进程下所有线程的统计情况。其中的PID与堆栈信息中nid对应nid为16进制kill -3 进程号,打印线程堆栈pstack 线程号打印本地线程堆栈在第二步中的线程堆栈中找到最耗CPU的pid对应的nid号如果是纯java代码说明是java代码执行造成的如果是正在执行native方法说明问题代码在JNI代码中需要去第三步中得到的本地线程堆栈中根据最耗CPU的pid定位代码。如果在第4步找不到可能是JNI调用中重现创建新线程来执行了可能是虚拟机自身代码导致如频繁Full GC操作。对于耗时多的代码片段通过多次打印堆栈的方式找到资源不足导致性能下降代码分析原因分析看到大量的线程处于WATING状态表示等待资源释放可能是资源配置太少可能是资源长时间被占用没有释放最终越来越慢。线程不退出导致系统挂死原因分析线程挂死分析方法获取第一次堆栈信息等待一定时间获取第二次堆栈信息比较第一次和第二次堆栈信息找出一直活跃的线程。如果没有发现活跃的线程可能是其他原因。如果有可能是1线程正在执行死循环代码2资源不足或泄露当前线程阻塞在锁对象wait在锁对象状态3与外部程序通信场景外部程序通信阻塞内存泄露代码分析常见场景全局的集合类如HashMap在对象不再需要时忘记从集合类中移除。特别是抛异常情况下要确保remove操作能执行Runnable对象必须交给Thread运行否则永远不会消亡必须执行start函数流打开函数使用完需要用对应的关闭函数否则会造成泄露比如FileInputStream是否存在堆内存泄露的判断依据找到GC日志分析Full GC行参数分别表示GC前的堆内存大小GC后的堆内存大小堆最大值耗时。稳定运行一段时间后排除掉系统设计了大量缓存的场景如果GC后的堆内存大小是逐步增加一直到Xmx判断是发生了堆内存泄露。分析方法借助MemoryAnalysis工具
