性能调优专题
JVM篇
类加载机制
其中loadClass的类加载过程有如下几步：
加载 >> 验证 >> 准备 >> 解析 >> 初始化 >> 使用 >> 卸载
加载：在硬盘上查找并通过IO读入字节码文件，使用到类时才会加载，例如调用类的
main()方法，new对象等等，在加载阶段会在内存中生成一个代表这个类的
java.lang.Class对象，作为方法区这个类的各种数据的访问入口
验证：校验字节码文件的正确性
**准备：**给类的静态变量分配内存，并赋予默认值
**解析：**将符号引用替换为直接引用，该阶段会把一些静态方法(符号引用，比如
main()方法)替换为指向数据所存内存的指针或句柄等(直接引用)，这是所谓的静态链接过
程(类加载期间完成)，动态链接是在程序运行期间完成的将符号引用替换为直接引用，下
节课会讲到动态链接
初始化：对类的静态变量初始化为指定的值，执行静态代码
java.exe调用底层的jvm.dll创建jvm 再创建一个引导类加载器实例（C++实现）
在调用java代码创建jvm启动器实例sun.misc.Launcher，该类由引导类加载器负责加载
调用getLauncher（）获取自己的加载器ClassLoader，AppClassLoader的实例
launcher.getClassLoad（）调用loadcCass加载要运行的类
类加载器
引导类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如
rt.jar、charsets.jar等
扩展类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR
类包
应用程序类加载器：负责加载ClassPath路径下的类包，主要就是加载你自己写的那
些类
自定义加载器：负责加载用户自定义路径下的类包
为什么要设计双亲委派机制？
沙箱安全机制：自己写的java.lang.String.class类不会被加载，这样便可以防止核心
API库被随意篡改
避免类的重复加载：当父亲已经加载了该类时，就没有必要子ClassLoader再加载一
次，保证被加载类的唯一性
自定义类加载器 继承classload类 重写loadclass（向上委派） findclass（向下委派，空的）
为什么要打破双亲委派机制？
tomacat 要让 每个web应用 加载的类库版本不同，互相隔离 ，
对于各个 webapp中的 class和 lib，需要相互隔离，不能出现一个应用中加载的类库会影响另一个应用的情况，而对于许多应用，需要有共享的lib以便不浪费资源。
与 jvm一样的安全性问题。使用单独的 classloader去装载 tomcat自身的类库，以免其他恶意或无意的破坏；
热部署。相信大家一定为 tomcat修改文件不用重启就自动重新装载类库而惊叹吧。实现也就是在后台有个线程做定时任务隔段时间就把jspclassload加载器引用==null，再重新加载
//非自定义的类还是走双亲委派加载
if (!name.startsWith(“com.tuling.jvm”)){
c = this.getParent().loadClass(name);
}else{
c = findClass(name);
}
JVM内存模型和内存参数设置
java ‐Xms2048M ‐Xmx2048M ‐Xmn1024M ‐Xss512K ‐XX:MetaspaceSize=256M ‐XX:MaxMetaspaceSize=256M ‐jar microservice‐eurek
a‐server.jar
堆 {[ 新生代 (年轻代)(Eden:s0:s1=8:1:1)-Xmn]}:{ 老年代}=1:2 对象实例存放地
-Xms（堆内存初始大小） -Xmx （堆内存最大值）
-Xms可以设置与-Xmx相同,以避免每次垃圾回收完成后JVM重新分配内存。
-Xmn设置年轻代大小此值对系统性能影响较大,官方推荐配置为整个堆的3/8。
方法区（永久代/元空间）类加载的信息存放地 常量池，静态变量，类信息
类被加载到方法区中后主要包含 运行时常量池、类型信息、字段信息、方法信息、类加载器的引用、对应class实例的引用等信息
-XX:MetaspaceSize=N
指定元空间触发Fullgc的初始阈值(元空间无固定初始大小)， 以字节为单位，默认是21M，达到该值就会触发
full gc进行类型卸载， 同时收集器会对该值进行调整： 如果释放了大量的空间， 就适当降低该值； 如果释放了很少的空间， 那么在不超
过-XX：MaxMetaspaceSize（如果设置了的话） 的情况下， 适当提高该值。这个跟早期jdk版本的-XX:PermSize参数意思不一样，-
XX:PermSize代表永久代的初始容量。默认64M（64位85M）
由于调整元空间的大小需要Full GC，这是非常昂贵的操作，如果应用在启动的时候发生大量Full GC，通常都是由于永久代或元空间发生
了大小调整，基于这种情况，一般建议在JVM参数中将MetaspaceSize和MaxMetaspaceSize设置成一样的值，并设置得比初始值要大，
对于8G物理内存的机器来说，一般我会将这两个值都设置为256M。
-XX:MaxMetaspaceSize=N
`设置元空间最大值， 默认是-1， 即不限制， 或者说只受限于本地内存大小。`
栈：每个线程都包含（栈【栈帧(局部变量表，操作数栈，动态链接，方法出口)】，本地方法 栈，程序计数器）
-Xss 每个栈的大小 默认1M 这里设置了512K
-Xss设置越小count值越小，说明一个线程栈里能分配的栈帧就越少，但是对JVM整体来说能开启的线程数会更多，但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000 左右。
本地方法栈 跟C++相关的代码了
程序计数器 让你知道继续从哪行代码执行
**（线程）栈，本地方法栈，程序计数器 都是线程共享的 **
GC方法配置
-XX:+UseParallelGC:选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下,年轻代使用并发收集,而年老代仍旧使用串行收集。
-XX:ParallelGCThreads=20:配置并行收集器的线程数,即:同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。
JVM优化，
能否对jvm调优，让其不要发生fullgc(会有swt机制，停止线程运行来gc，)
java ‐Xms3072M ‐Xmx3072M ‐Xmn2048M ‐Xss1M ‐XX:MetaspaceSize=256M
‐XX:MaxMetaspaceSize=256M ‐jar microservice‐eurek
a‐server.jar
就是尽可能让对象都在新生代里分配和回收，尽量别
让太多对象频繁进入老年代，避免频繁对老年代进行垃圾回收，同时给系统充足的内存大小，避免新生代频繁的进行垃圾回收
-Xloggc:d:\gc.log 生成gc 的日志
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=d:\gc.dump 发生oom 自动生成dump的文件名和目录
-Xms20M //最大堆内存
-Xmx20M //最小堆内存
-XX:+PrintGC 输出GC日志
-XX:+PrintGCDetails 输出GC的详细日志
-XX:+PrintGCTimeStamps 输出GC的时间戳(以基准时间的形式))
-XX:+PrintHeapAtGC 在进行GC的前后打印出堆的信息
-Xmx4096m -Xms1024m
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/heapdump.hprof
nohup java
-Xmx4096m -Xms1536m -XX:NewRatio=1:2 -XX:SurvivorRatio=1:2
-Djava.rmi.server.hostname=192.168.129.129 -Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9090
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false -jar easDmsync.jar
1.老年代回收是否频繁
- 老年代可用内存是否放逐渐缩小，最后导致堆扩容
- 出现内存问题了可以直接用mat分析、Jconsole都很直接了当(尽量不要使用Jhat，很吃内存，不直观、浪费时间)
- 如果是linux服务器并且本地可以远程到服务的话，可以配置如下的启动参数，使用远程的方式。
-Djava.rmi.server.hostname=192.168.129.129 -Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9090
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
- 如果方法4不行的话，最基本的就靠指令了，如jmap、jstat、jstack等了，也可以导出dump文件，用mat分析。这是最坏的情况。
.jvm常用命令
1.jmap 观察运行中的jvm物理内存的占用情况。
jmap -histo pid 查看实例个数和内存大小，linux环境很好用
jmap -F -dump:live,file=jmap.hprof pid 导出内存dump文件，之后可以用mat分析
2.jstat JVM统计监测工具
jstat [ generalOption | outputOptions vmid [interval[s|ms] [count]] ]
jstat -gc pid 5000 定时查看新、老容量和使用情况
jstat -gc 21711 250 4
vmid是Java虚拟机ID，在Linux/Unix系统上一般就是进程ID。interval是采样时 间间隔。count是采样数目。比如下面输出的是GC信息，采样时间间隔为250ms，采样数为4
jstat -gcutil pid 和上面差不多
3.jstack 观察jvm中当前所有线程的运行情况和线程当前状态
配合top使用，可以先查看消耗cpu多进程 top -p pid -H
jstack pid 查看线程状态，如死锁检测
jstack -m pid（ 查看 java 和 native c/c++ 框架的所有栈信息）
jstack -l pid（ 查看 关于锁的附加信息）
jstack -F pid（ 当 ’jstack [-l] pid’ 没有相应的时候强制打印栈信息）
4.jps 列出所有的jvm实例
工具路径:jdk1.7.0_03\bin
运行模式： 命令行
命令格式： jps [options] [hostid]
注： 如果不指定hostid就默认为当前主机或服务器。
常用命令：jps -q（查看 pid）
jps -m （ 查看传递给main 方法的参数）
jps -l （ 查看main类或Jar的全限名）
jps -v （查看 传入JVM的参数）
1472
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
