黑马JVM总结(三)

(1)栈内存溢出

黑马JVM总结(三)_第1张图片

方法的递归调用,没有设置正确的结束条件,栈会有用完的一天,导致栈内存溢出

黑马JVM总结(三)_第2张图片

黑马JVM总结(三)_第3张图片

黑马JVM总结(三)_第4张图片

黑马JVM总结(三)_第5张图片

黑马JVM总结(三)_第6张图片

可以修改栈的大小:

黑马JVM总结(三)_第7张图片

黑马JVM总结(三)_第8张图片

再次运行:减少了次数

黑马JVM总结(三)_第9张图片

案例二:

黑马JVM总结(三)_第10张图片

黑马JVM总结(三)_第11张图片

黑马JVM总结(三)_第12张图片

黑马JVM总结(三)_第13张图片

两个类的循环应用问题,导致Json解析时会出现 

黑马JVM总结(三)_第14张图片

解决:员工不在关联部门了,转换时忽略这个属性转换,打破这个循环引用依赖

黑马JVM总结(三)_第15张图片

黑马JVM总结(三)_第16张图片

(2)线程诊断_CPU占用高

线程更虚拟机栈是息息相关的

黑马JVM总结(三)_第17张图片

黑马JVM总结(三)_第18张图片 

后台运行一段java代码:

使用top命令查看一下后天运行:

黑马JVM总结(三)_第19张图片

黑马JVM总结(三)_第20张图片

可以看到有问题的进程编号,top命令只能定位到进程,定位不到那个线程导致的

可以使用ps,命令来查看线程的占用

H:打印进程的进程数,进程里面的线程信息

-eo:规定输入的内容

pid:进程id

tid:线程id

%cpu:对cpu的占用情况

黑马JVM总结(三)_第21张图片

已知进程编号,可以进行筛选  grep

黑马JVM总结(三)_第22张图片

还可以说那个jdk的一个工具进行定位:jstack 进程id

这一它输出的是十六进制的,先要把32655进行转化一下16进制 7F99

黑马JVM总结(三)_第23张图片

黑马JVM总结(三)_第24张图片 他这里详细的打印了哪行代码出现了问题黑马JVM总结(三)_第25张图片

就可以定位源代码:黑马JVM总结(三)_第26张图片 

(3)线程诊断_迟迟得不到结果-死锁

运行另外一个程序:让他输出一个结果,但是久久没有输出,可能是因为线程死锁导致的怎么排查呢? 

黑马JVM总结(三)_第27张图片

最后有显示死锁 Thread0和Thread1,下面有错误的位置

黑马JVM总结(三)_第28张图片

黑马JVM总结(三)_第29张图片

线程1等待线程0释放a对象的锁,线程线程0等待线程1释放b对象的锁,而导致相互等待,死锁

 

你可能感兴趣的:(JVM虚拟机,jvm)