jvm调优

概述 命令jmap是一个多功能的命令。它可以生成 java 程序的 dump 文件， 也可以查看堆内对象示例的统计信息、查看 ClassLoader 的信息以及 finalizer 队列。 jmap 用法 参数： option： 选项参数。 pid： 需要打印配置信息的进程ID。 executable： 产生核心dump的Java可执行文件。 core： 需要打印配置信息的核心文件。 server-id 可选的唯一id，如果相同的远程主机上运行了多台调试服务器，用此选项参数标识服务器。 remote server IP or hostname 远程调试服务器的IP地址或主机名。 option no option： 查看进程的内存映像信息,类似 Solaris pmap 命令。 heap： 显示Java堆详细信息 histo[:live]： 显示堆中对象的统计信息 clstats： 打印类加载器信息 finalizerinfo： 显示在F-Queue队列等待Finalizer线程执行finalizer方法的对象 dump:<dump-options>： 生成堆转储快照 F： 当-dump没有响应时，使用-dump或者-histo参数. 在这个模式下,live子参数无效. help： 打印帮助信息 J<flag>： 指定传递给运行jmap的JVM的参数 示例一：no option 命令

1. 数据类型 java 虚拟机中，数据类型可以分为两类：基本类型和引用类型。 基本类型的变量保存原始值，即：它代表的值就是数值本身，而引用类型的变量保存引用值。 “引用值”代表了某个对象的引用，而不是对象本身，对象本身存放在这个引用值所表示的地址的位置。 基本类型包括：byte、short、int、long、char、float、double、boolean 引用类型包括：类类型、接口类型和数组 byte 1B(8位) -128 ~ 127 0 short 2B(16位) -2 15 ~ 2 15 -1 0 Int 4B(32位) -2 31 ~ 2 31 -1 0 long 8B(64位) -2 63 ~ 2 63 -1 0 char 2B(16位) 0 ~ 2 16 -1 \U0000 float 4B(32位) 1.4013E-45 ~3.4028E+38 0.0F double 8B(64位) 4.9E-324 ~1.7977E+308 0.0D boolean 1B(8位) True, false false 2. 堆（ heap ）与栈（ stack ） 堆和栈是程序运行的关键，很有必要它他们的关系说清楚。 在java中，Main函数就是栈的起始点，也是程序的起始点。程序要运行总是有一个起点的（程序执行的入口）。 概括： 1 栈是运行时的单位 , 而堆是存储的单元 。

JVM调优（三）——基于Btrace的监控调试 简介 Btrace可以动态地向目标应用程序的字节码注入追踪代码 用到的技术： JavaComplierApi、JVMTI、Agent、Instrumentation+ASM Btrace安装入门 通过github搜索进行下载 新建环境变量BTRACE_HOME 添加Path:%BTRACE_HOME%\bin 两种运行脚本的方式 在JVisualVM中添加Btrace插件，添加classpath 使用命令行btracce <pid> Btrace使用详解 ### 拦截方法 普通方法 @OnMethod(clazz="",method="") 构造函数 @OnMethod(clazz="",method="<init>") 拦截同名函数，用参数区分 拦截时机 Kind.ENTRY:入口，默认值 Kind.RETURN:返回 Kind.THROW:异常 Kind.Line:行 拦截this，参数，返回值 this: @Self 入参：可以用AnyType,也可以用真实类型，同名的用真实的 返回：@Return 简单类型：直接获取 复杂类型：反射，类名+属性名 其他 打印行号：Kind.LINE 打印堆栈：Thread.jstack() 打印环境变量 使用注意事项 默认只能本地运行 生产环境可以使用，但是被修改的字节码不会被还原 来源：

1、串行垃圾收集器线程：单线程，无需线程交互，效率高；适用于单核处理器，或者小数据量（100M）情况下 ； -XX:UseSerialGC : 打开串行收集器 2、并行垃圾收集器线程：多线程，减少垃圾回收时间，适用于多核处理器； 　　-XX:UseParallelGC : 打开串行收集器，仅用于新生代； 　　-XX:UseParallelOldGC： 打开串行收集器，仅用于老年代； 　　-XX:UseParallelGCThreads=n；垃圾回收线程数量，n 建议设置成CPU的核数 　　-XX:MaxGcPauseMills=n；垃圾回收的时候，回收空间，用户线程创建空间，为避免回收时同时开辟和回收空间，所以回收时会暂停所有用户线程，n：表示最大暂停时间 　　-XX:GCTimeRatio=n；这个值会影响应用程序的吞吐量，吞吐量 = 垃圾回收时间 / 非垃圾回收时间；公式为 1 / （1 + n）;默认99 表示：1%的时间用于垃圾回收 3、并发垃圾收集器线程： 来源： https://www.cnblogs.com/wangshunyao/p/11684643.html

CMS收集器 CMS收集器是基于“标记—清除”算法实现，整个过程分为4个步骤，包括： 初始标记（CMS initial mark） 并发标记（CMS concurrent mark） 重新标记（CMS remark） 并发清除（CMS concurrent sweep） 其中，初始标记、重新标记这两个步骤仍然需要“Stop The World”。 初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快 并发标记阶段就是进行GC Roots Tracing的过程 重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录， 这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。 CMS收集器无法处理浮动垃圾（Floating Garbage），可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。 由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生， 这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。 这一部分垃圾就称为“浮动垃圾”。 也是由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留有足够的内存空间给用户线程使用， 因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集

这是jvm优化系列第二篇： jvm优化——垃圾回收 通过上一篇的jvm垃圾回收知识，我们了解了jvm对内存分配以及垃圾回收是怎么来处理的。理论是指导实践的工具，有了理论指导，定位问题的时候，知识和经验是关键基础，数据可以为我们提供依据。 在常见的线上问题时候，我们多数会遇到以下问题： 内存泄露 某个进程突然cpu飙升 线程死锁 响应变慢...等等其他问题。 如果遇到了以上这种问题，在线下可以有各种本地工具支持查看，但到线上了，就没有这么多的本地调试工具支持，我们该如何基于监控工具来进行定位问题? 我们一般会基于数据收集来定位，而数据的收集离不开监控工具的处理，比如：运行日志、异常堆栈、GC日志、线程快照、堆快照等。经常使用恰当的分析和监控工具可以加快我们的分析数据、定位解决问题的速度。以下我们将会详细介绍。 一、jvm常见监控工具&指令 1、 jps:jvm进程状况工具 jps [options] [hostid] 如果不指定hostid就默认为当前主机或服务器。 命令行参数选项说明如下： -q 不输出类名、Jar名和传入main方法的参数 - l 输出main类或Jar的全限名 -m 输出传入main方法的参数 - v 输出传入JVM的参数 例如: 2、jstat: jvm统计信息监控工具 jstat 是用于见识虚拟机各种运行状态信息的命令行工具

1. 杂项 -classpath your_dir ： 指定目录，jvm将会默认加载该目录下的类 -Djava.library.path=library_dir ： 指定java的JNI相关文件dll的位置 -server ： jvm将会以server模式启动应用，启动较慢，性能较好 -client ： jvm将会以client模式启动应用，启动较快，性能较差 -Dsun.rmi.transport.tcp.responseTimeout=20000 ： 设定RMI请求超时时间 -Dcom.sun.management.jmxremote ： 支持远程通过jmx的方式监控应用资源 -Dcom.sun.management.jmxremote.port=9999 ： 远程RMI使用JMX时的监听端口 -Dcom.sun.management.jmxremote.ssl=false ： 远程RMI使用JMX时不使用SSL协议 -Dcom.sun.management.jmxremote.authenticate=false ： 远程RMI使用JMX时不需要验证信息 -Djava.util.logging.config.file=properties_dir： 指定java自带的日志系统的配置文件 -Djava.util.logging.manager=manager_package：

Java垃圾回收概况 　　Java GC（Garbage Collection，垃圾收集，垃圾回收）机制，是Java与C++/C的主要区别之一，作为Java开发者，一般不需要专门编写内存回收和垃圾清理代码，对内存泄露和溢出的问题，也不需要像C程序员那样战战兢兢。这是因为在Java虚拟机中，存在自动内存管理和垃圾清扫机制。概括地说，该机制对JVM（Java Virtual Machine）中的内存进行标记，并确定哪些内存需要回收，根据一定的回收策略，自动的回收内存，永不停息（Nerver Stop）的保证JVM中的内存空间，防止出现内存泄露和溢出问题。 　　关于JVM，需要说明一下的是，目前使用最多的Sun公司的JDK中，自从1999年的JDK1.2开始直至现在仍在广泛使用的JDK6，其中默认的虚拟机都是HotSpot。2009年，Oracle收购Sun，加上之前收购的EBA公司，Oracle拥有3大虚拟机中的两个：JRockit和HotSpot，Oracle也表明了想要整合两大虚拟机的意图，但是目前在新发布的JDK7中，默认的虚拟机仍然是HotSpot，因此本文中默认介绍的虚拟机都是HotSpot，相关机制也主要是指HotSpot的GC机制。 　　Java GC机制主要完成3件事：确定哪些内存需要回收，确定什么时候需要执行GC，如何执行GC。经过这么长时间的发展（事实上

今天处理了一次性能问题，记录一下处理的过程。 早上发现几台机器负载非常高，前端nginx的连接数接近2000。 后端的应用服务器的响应情况很忙，最糟糕的情况达到了30多万毫秒。 top看到进程运行情况： PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3182 root 25 0 1028m 560m 9296 S 289.6 29.6 27:22.26 java 3220 root 25 0 1039m 678m 9308 S 108.3 35.8 27:17.61 java 1 root 15 0 2084 608 524 S 0.0 0.0 0:55.82 init 确定了是应用服务器程序占用了大部分cpu 接着运行top -H -p 3182 看到占用最高的cpu的java进程号。 jstack 显示该jvm进程中所有线程的调用栈已经线程所处的状态(jdk5.0以上支持)。 jstack pid | less 查找上述进程号的十六进制数字，比如nid=0x1613d（小写） 找出对应的进程 java.lang.Thread.State: RUNNABLE at net.sf.json.util.JSONTokener.nextClean(JSONTokener.java:207) at net.sf.json

摘抄并用于自查 JVM内存模型 　　1. Java程序具体执行的过程：　 Java源代码文件（.java后缀）会被Java编译器编译为字节码文件（.class后缀） 由JVM中的类加载器加载各个类的字节码文件，加载完毕后，交由JVM执行引擎执行 在整个程序执行过程中，JVM会用一段空间来存储程序执行期间需要用到的 数据和相关信息 ，这段空间一般被称作为 Runtime Data Area（运行时数据区），也就是我们常说的JVM内存 因此，在Java中我们常常说到的内存管理就是针对这段空间进行管理（如何分配和回收内存空间） 　　2. JVM的内存划分和各区域职责： 　　　 程序计数器：程序计数器是指CPU中的寄存器，它保存的是程序当前执行的指令地址（也可以说保存下一条指令的所在存储单元的地址），当CPU需要执行指令时，需要从程序计数器中得到当前需要执行的指令所在存储单元的地址，然后根据得到的地址获取到指令，在得到指令之后，程序计数器便自动加1或者根据转移指针得到下一条指令的地址，如此循环，直到执行完所有的指令。（注：JVM中的程序计数器并不像汇编语言中的程序计数器一样是物理概念上的CPU寄存器，但是逻辑作用上是等同的，在JVM中多线程是通过线程轮流切换来获得CPU执行时间的，在任一具体时刻，一个CPU的内核只会执行一条线程中的指令