JVM相关问题
- 一、Java继承时父子类的初始化顺序是怎样的?
- 二、JVM类加载的双亲委派模型?
- 三、JDK为什么要设计双亲委派模型,有什么好处?
- 四、可以打破JVM双亲委派模型吗?如何打破JVM双亲委派模型?
- 五、什么是内存溢出?什么是内存泄漏?
- 内存溢出(OOM):OutOfMemory
- 内存泄露:Memory Leak
- 六、线上项目JVM都怎么设置的?
- 七、线上Java项目服务器内存飙升怎么排查处理?
- 八、线上Java项目服务器CPU飙到100%怎么排查?
- 九、JVM发生OOM后,其他线程是否可以继续工作?
- 十、高并发系统的JVM如何优化?
- 1、内存预估
- 2、内存分配
- 3、内存占用动态推算
- 4、如何调优?
一、Java继承时父子类的初始化顺序是怎样的?
- 父类–静态变量
- 父类–静态初始化块
- 子类–静态变量
- 子类–静态初始化块
- 父类–变量
- 父类–初始化块
- 父类–构造器
- 子类–变量
- 子类–初始化块
- 子类–构造器
二、JVM类加载的双亲委派模型?
三、JDK为什么要设计双亲委派模型,有什么好处?
1、确保安全,避免Java核心类库被修改;
2、避免重复加载;
3、保证类的唯一性;
如果你写一个java.lang.String的类去运行,发现会抛出如下异常;
四、可以打破JVM双亲委派模型吗?如何打破JVM双亲委派模型?
答案:可以;
想要打破这种模型,那么就自定义一个类加载器,重写其中的loadClass
方法,使其不进行双亲委派即可;
五、什么是内存溢出?什么是内存泄漏?
内存溢出(OOM):OutOfMemory
指程序在申请内存时,没有足够的内存空间供其使用,抛出OutOfMemory
错误;
比如申请了一个8MB空间,但是当前内存可用空间只有5MB,那么就是内存溢出;
即:OutOfMemoryError,是指没有空闲内存,垃圾收集器回收后也不能提供更多的内存空间;
内存泄露:Memory Leak
指程序运行后,没有释放所占用的内存空间,一次内存泄漏可能不会有很大的影响,但长时间的内存泄漏,堆积到一定程度就会产生内存溢出;
(1)单例对象,生命周期和应用程序一样长,如果单例对象持有对外部对象的引用的话,那么这个外部对象是不能被回收的,则会产生内存泄露;
(2)一些资源未关闭也会导致内存泄漏,比如数据库连接,网络连接socket和IO流的连接都必须在 finally 中 close,否则不能被回收的;
六、线上项目JVM都怎么设置的?
假设线上:4核8G机器;
JVM:栈、堆、元空间;
1、栈: 1m(默认大小),-Xss512k,一个线程是1m,一个线上项目 Tomcat 可能有300个线程,300m;
2、堆:大概把机器的一半内存给堆,4G(新生代、老年代);
- CMS:1/3 、2/3
- G1: 6:4
3、元空间: 一般512M肯定够了;
此时JVM参数如下:-Xms4096M -Xmx4096M -Xss1M -XX:MetaspaceSize=512M -XX:MaxMetaspaceSize=512M -XX:+UseG1GC
七、线上Java项目服务器内存飙升怎么排查处理?
在Linux系统中使用命令:
#(查看系统Java相关的进程)
jps
在Linux系统中使用命令:
# 查看进程内存占用情况
top
可使用快捷键排序:shift + m
在Linux系统中使用命令:
# 查看内存信息
jmap -histo pid
- jmap 是Java虚拟机(JVM)自带的一个命令行工具,用于生成Java进程的内存映像文件(heap dump),它通过与Java进程通信获取内存信息,并将信息输出到文件中,以便后续离线分析。
- -histo 查看堆内存中的对象实例数目、内存占用大小、类名等;
在Linux系统中使用命令:
# 将内存信息转存文件
jmap -dump:format=b,file=heap.hprof pid
通过使用 MemoryAnalyzer(MAT)工具分析转存下来的文件。
八、线上Java项目服务器CPU飙到100%怎么排查?
# 查看进程内存占用情况
top
# 打印线程栈信息,输出到fileName.txt文件中
jstack pid > fileName.txt
# 查看pid进程中的线程内存占用情况
top -H -p pid
# 把十进制线程ID转换为十六进制
printf '%x' tid
九、JVM发生OOM后,其他线程是否可以继续工作?
要分情况看,不一定;
- 如果发生OOM,例如使用局部变量存放对象,方法执行后内存会释放,那么其他线程可以继续工作;
- 如果发生OOM,例如使用全局变量存放对象,方法执行后内存不会释放,那么其他线程不可以继续工作;
使用 VisualVM 工具查看JVM堆内存变化情况
十、高并发系统的JVM如何优化?
如果每秒发生 583000 请求:
1、内存预估
-
普通4核8G服务器,一台机器抗300-400并发下单请求比较合理;
-
583000 / 300 = 1943台机器;
-
一个订单预估1KB;
-
一台机器,300KB * 20 * 10 = 60MB的内存开销,一秒后60MB对象就成为垃圾;
2、内存分配
- 4核8G的机器,JVM给4G,剩下几个G会留给操作系统;
- 堆3G(新生代1.5G,老年代1.5G)
- 栈1MB,JVM里大概会有300-500个线程,大概300-500MB;
- 元空间/永久代512MB;
- -Xms3072M -Xmx3072M -Xmn1536M -Xss1M
- -XX:MetaspaceSize=512M -XX:MaxMetaspaceSize=512M
- -XX:+PrintGCDetails
- -XX:+PrintGCDateStamps
- -Xloggc:d:/gc.log
- -XX:+HeapDumpOnOutOfMemoryError
- -XX:HeapDumpPath=d:/heap.hprof
3、内存占用动态推算
- 一台机器每秒抗300个订单,300KB * 20 * 10 = 60MB,每秒占据新生代60MB内存空间,新生代总共有1.5G的内存空间;
- 1.5G * 1024MB / 60MB = 25秒 新生代Eden占满,触发Minor GC;
- 一般情况下一次可以回收掉90%的新生代对象,存活对象 = 1.5G * 1024MB * 10% = 150MB;
- 如果 “-XX:SurvivorRatio” 参数默认值为8,那么:新生代Eden=1.2GB、S0 = 150MB、S1 = 150MB;
4、如何调优?
(1):
-
1次Minor GC后,可能Survivor不足或者触发动态年龄判断,对象进入老年代,明显是 Survivor 空间不足;
-
新生代调整为2G,老年代为1G,此时Eden:1.6G,每个Survivor:200MB;
-
解决 Survivor 不足或者触发动态年龄判断,降低新生代对象进入老年代的概率;
-
此时JVM参数:
-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=512M -XX:MaxMetaspaceSize=512M
(2):
- 一般系统里的@Service、@Controller之类的注解需要长期存活,这些对象一般也不会很多,可能几十兆,应该让它们尽快进入老年代;
- 此时JVM参数:
-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:MaxTenuringThreshold=5
(3):
-
一般情况下,大对象可能需要长期存活和使用,让它直接进入老年代;(根据项目实际情况来确定)
-
此时JVM参数如下:
-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:MaxTenuringThreshold=5 -XX:PretenureSizeThreshold=1M
(4):
- 指定合适的垃圾回收器;
- 此时JVM参数 :
-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:MaxTenuringThreshold=5 -XX:PretenureSizeThreshold=1M -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
- 小堆内存不使用G1垃圾收集器;
(5):
- 大概每隔几分钟Minor GC之后有大概200MB左右对象进入老年代,推算可能差不多1小时后,才会有接近1GB的对象进入老年代,触发Full GC,然后高峰期一过,可能需要几个小时才会一次Full GC;
-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:-UseCompressedClassPointers -XX:MetaspaceSize=512M -XX:MaxMetaspaceSize=512M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=5 -XX:PretenureSizeThreshold=1M -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:d:/gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=d:/heap.hprof
(6): 优化思路
- 1、尽可能让对象在新生代里分配和回收,避免对象频繁进入老年代导致老年代频繁垃圾回收;
- 2、给系统充足的内存空间,避免新生代频繁的垃圾回收;
- 3、指定合适的垃圾收集器;