VisualVM

tomcat服务器优化 1、JDK内存优化 根据服务器物理内容情况配置相关参数优化tomcat性能。当应用程序需要的内存超出堆的最大值时虚拟机就会提示内存溢出，并且导致应用服务崩溃。因此一般建议堆的最大值设置为可用内存的最大值的80%。 Tomcat默认可以使用的内存为128MB，在较大型的应用项目中，这点内存是不够的，需要调大. Tomcat默认可以使用的内存为128MB,Windows下,在文件/bin/catalina.bat，Unix下，在文件 /bin/catalina.sh 的前面，增加如下设置： JAVA_OPTS='-Xms【初始化内存大小】 -Xmx【可以使用的最大内存】 -XX:PermSize=64M -XX:MaxPermSize=128m' 需要把几个参数值调大。例如： JAVA_OPTS='-Xms256m -Xmx512m' 表示初始化内存为256MB，可以使用的最大内存为512MB。 参数详解 -server 启用jdk 的 server 版； -Xms java虚拟机初始化时的最小内存； -Xmx java虚拟机可使用的最大内存； -XX:PermSize 内存永久保留区域 -XX:MaxPermSize 内存最大永久保留区域 -Xmn jvm最小内存 32G 内存配置示例： JAVA_OPTS="$JAVA_OPTS -Xms10g

本文已被Github仓库收录 https://github.com/silently9527/JavaCore 微信公众号：贝塔学Java 前言 前几天中午正在和同事最近聊股市较好，这几天每天都可以喝点肉汤，心里还是挺高兴的；正在这个时候收到了线上告警邮件和运维同学的消息，“你们有服务挂了！”，心里一紧，立马打开电脑看来下线上cat监控大盘，发现很多服务都在报错，根据cat上的监控日志很快发现了其中一个服务内存溢出导致其他调用服务也有问题，竟然已经定位到了出问题的服务，那就简单了，没有是重启解决不了的问题，重启之后很快服务都恢复正常了。几分钟之后又报错了，同样也是这个服务内存溢出，经过排查后发现该服务的堆内存被改小了，好家伙，运维同学不讲武德，搞偷袭，趁我没反应过来调了内存，内存调整回去之后服务就恢复了正常。 事后把线上的快照文件拖了下来分析，发现本身这个项目的代码也有些问题，本文就整理了一下JVM常用的分析工具。 命令行工具 在安装完JDK之后在JAVA_HOME/bin目录下JDK已经提供了很多命令行的工具 可能我们最常用的就是 java 、 javac 这两个命令，除了这两个命令之外还有提供很多其他的实用工具，本文主要来一起学习对JVM监控诊断工具 虚拟机进程状况工具（jps） 该工具的功能比较单一，与linux中的ps功能类似，用来列出正在运行的虚拟机进程

工具做为图形化界面来展示更能直观的发现问题，另一方面一些耗费性能的分析（dump文件分析）一般也不会在生产直接分析，往往dump下来的文件达1G左右，人工分析效率较低，因此利用工具来分析jvm相关问题，长长可以到达事半功倍的效果来。 jvm监控分析工具一般分为两类，一种是jdk自带的工具，一种是第三方的分析工具。jdk自带工具一般在jdk bin目录下面，以exe的形式直接点击就可以使用，其中包含分析工具已经很强大，几乎涉及了方方面面，但是我们最常使用的只有两款：jconsole.exe和jvisualvm.exe；第三方的分析工具有很多，各自的侧重点不同，比较有代表性的：MAT(Memory Analyzer Tool)、GChisto等。 对于大型 JAVA 应用程序来说，再精细的测试也难以堵住所有的漏洞，即便我们在测试阶段进行了大量卓有成效的工作，很多问题还是会在生产环境下暴露出来，并且很难在测试环境中进行重现。JVM 能够记录下问题发生时系统的部分运行状态，并将其存储在堆转储 (Heap Dump) 文件中，从而为我们分析和诊断问题提供了重要的依据。其中VisualVM和MAT是dump文件的分析利器。 jdk自带的工具 jconsole Jconsole（Java Monitoring and Management Console）是从java5开始

目录： 第1节说在前面的话 00:05:07分钟 | 第3节环境搭建以及jdk,jre,jvm的关系 00:20:48分钟 | 第5节jvm再体验-jvm可视化监控工具 00:21:17分钟 | 第7节Java的发展历史00:27:24分钟 | 第9节Java技术体系00:08:46分钟 | 第11节lanmbda表达式简介00:07:02分钟 | 第13节Java虚拟机-ExactVM00:03:35分钟 | 第15节Java虚拟机-kvm00:03:04分钟 | 第17节Java虚拟机-j900:04:23分钟 | 第19节Java虚拟机-MicrosoftJVM00:03:57分钟 | 第21节Java虚拟机-TaobaoVM00:03:06分钟 | 第23节Java内存区域-Java虚拟机栈00:12:04分钟 | 第25节Java内存区域-本地方法栈00:02:39分钟 | 第27节Java内存区域-方法区00:06:32分钟 | 第29节对象在内存中的布局-对象的创建00:21:19分钟 | 第31节深入理解对象的访问定位00:08:01分钟 | 第33节垃圾回收-判断对象是否存活算法-引用计数法详解00:14:08分钟 | 第35节垃圾回收算法-标记清除算法00:04:36分钟 | 第37节垃圾回收算法-标记整理算法和分代收集算法00:05:24分钟 |

模型系统加载深度学习模型后，会触发报警，原因是触发了 Full GC，而 GC 后回收效率却不高，回收前 83%，回收后 65%，老年代加载完成单率模型后，竟然从 150M 飙到了 1.5G 以上，而实际上用 jol 计算出来的模型大小才 300M，这明显是不符合预期的。最后排查发现实际是 跨代引用和循环依赖 导致的问题。 GC 日志 GC日志 整理如下： 服务启动 1 YGC，from survivor 占用 64% - 0.59s 2 YGC，from survivor 占用 24%，有 165823K 进入老年代，被回收的不多，差不多 10M - 0.43s 3 YGC，from survivor 占用 10%，老年代使用了 165823K，结果没变，但是发现 eden 区没有用满就触发 Young GC 了，Eden 区用了 47% - 0.03s 【这个过程是在 Full GC 之前，可以看到触发条件是 System.gc()】 - 初始标记 0.01s STW - 并发标记 0.03s - 并发预清理 0.01s + 5.4s - 最后标记 0.11s STW - 并发清理 0.15s - 并发重启 0.04s 也就是说这次 Full GC 有 0.12s 会 Stop the world，而最后老年代还剩余 165820K，回收了 3K 4 YGC，from