jvm内存模型及jvm调优

最新推荐文章于 2024-04-16 03:19:43 发布

qq_39727896

最新推荐文章于 2024-04-16 03:19:43 发布

阅读量194

点赞数

分类专栏：技术

本文链接：https://blog.csdn.net/qq_39727896/article/details/114167491

版权

技术专栏收录该内容

37 篇文章 0 订阅

订阅专栏

JVM 内存模型

堆和栈：

在Java中一个线程就会相应有一个线程栈与之对应，（因为不同的线程执行逻辑有所不同，因此需要一个独立的线程栈）。而堆则是所有线程共享的。栈因为是运行单位，因此里面存储的信息都是跟当前线程（或程序）相关信息的。包括局部变量、程序运行状态、方法返回值等等；而堆只负责存储对象信息。

堆中存的是对象。栈中存的是基本数据类型和堆中对象的引用，需要特别注意的是：

1. 与C不同的是，Java中没有指针的概念

2. 程序运行永远都是在栈中进行的，因而参数传递时，只存在传递基本类型和对象引用的问题。不会直接传对象本身。

基本数据类型的内存占用空间要远远小于包装类（因为包装类已经转化为对象了），因此代码中尽量多使用基本数据类型。

堆分为：

1.年轻代：Eden(800M) ,s0(100M) ,s1(100M）

2.老年代：GC分代年龄达到15岁的对象放入老年代。

b)过大的对象直接放入老年代。为了避免为大对象分配内存时的复制操作而降低效率。

c)对象动态年龄判断。

d)minor gc后存活的对象在survivor区放不下

e)老年代空间分配担保机制。年轻代每次minor gc之前jvm都会计算老年代剩余可用空间，如果小于年轻代里所有对象大小之和（包括垃圾对象）查看设置的平境大小的参数，若大于就会触发full gc,对老年代和年轻代一起回收一次垃圾，如果回收完还是没有足够空间存放新的对象，就会发生oom.

gc算法：

1）引用计数（Reference Counting）:

比较古老的回收算法。原理是此对象有一个引用，即增加一个计数，删除一个引用则减少一个计数。垃圾回收时，只用收集计数为0的对象。此算法最致命的是无法处理循环引用的问题。

2）标记-清除（Mark-Sweep）:

此算法执行分两阶段。第一阶段从引用根节点开始标记所有被引用的对象，第二阶段遍历整个堆，把未标记的对象清除。此算法需要暂停整个应用，同时，会产生内存碎片。

3）复制（Copying）:

此算法把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区域中。次算法每次只处理正在使用中的对象，因此复制成本比较小，同时复制过去以后还能进行相应的内存整理，不会出现“碎片”问题。当然，此算法的缺点也是很明显的，就是需要两倍内存空间。

4）标记-整理（Mark-Compact）:

此算法结合了“标记-清除”和“复制”两个算法的优点。也是分两阶段，第一阶段从根节点开始标记所有被引用对象，第二阶段遍历整个堆，把清除未标记对象并且把存活对象“压缩”到堆的其中一块，按顺序排放。此算法避免了“标记-清除”的碎片问题，同时也避免了“复制”算法的空间问题。

jvm调优：对JVM内存的系统级的调优主要的目的是减少GC的频率和Full GC的次数。

1)年老代（Tenured）被写满

1.对于朝生夕死的对象，使其在年轻代的minor gc的时候就给回收到，不要等到老年代的full gc. 老年代的full gc 性能开销非常大。

调优时尽量让对象在新生代GC时被回收、让对象在新生代多存活一段时间和不要创建过大的对象及数组避免直接在旧生代创建对象。

2)持久代Pemanet Generation空间不足

增大Perm Gen空间，避免太多静态对象，控制好新生代和旧生代的比例

3)System.gc()被显示调用

垃圾回收不要手动触发，尽量依靠JVM自身的机制

内存泄漏检查

内存泄漏是比较常见的问题，而且解决方法也比较通用，这里可以重点说一下，而线程、热点方面的问题则是具体问题具体分析了。

内存泄漏一般可以理解为系统资源（各方面的资源，堆、栈、线程等）在错误使用的情况下，导致使用完毕的资源无法回收（或没有回收），从而导致新的资源分配请求无法完成，引起系统错误。

内存泄漏对系统危害比较大，因为他可以直接导致系统的崩溃。

需要区别一下，内存泄漏和系统超负荷两者是有区别的，虽然可能导致的最终结果是一样的。内存泄漏是用完的资源没有回收引起错误，而系统超负荷则是系统确实没有那么多资源可以分配了（其他的资源都在使用）。

年老代堆空间被占满

异常： java.lang.OutOfMemoryError: Java heap space

说明：

这是最典型的内存泄漏方式，简单说就是所有堆空间都被无法回收的垃圾对象占满，虚拟机无法再在分配新空间。
如上图所示，这是非常典型的内存泄漏的垃圾回收情况图。所有峰值部分都是一次垃圾回收点，所有谷底部分表示是一次垃圾回收后剩余的内存。连接所有谷底的点，可以发现一条由底到高的线，这说明，随时间的推移，系统的堆空间被不断占满，最终会占满整个堆空间。因此可以初步认为系统内部可能有内存泄漏。（上面的图仅供示例，在实际情况下收集数据的时间需要更长，比如几个小时或者几天）

解决：

这种方式解决起来也比较容易，一般就是根据垃圾回收前后情况对比，同时根据对象引用情况（常见的集合对象引用）分析，基本都可以找到泄漏点。

持久代被占满

异常：java.lang.OutOfMemoryError: PermGen space

说明：

Perm空间被占满。无法为新的class分配存储空间而引发的异常。这个异常以前是没有的，但是在Java反射大量使用的今天这个异常比较常见了。主要原因就是大量动态反射生成的类不断被加载，最终导致Perm区被占满。

更可怕的是，不同的classLoader即便使用了相同的类，但是都会对其进行加载，相当于同一个东西，如果有N个classLoader那么他将会被加载N次。因此，某些情况下，这个问题基本视为无解。当然，存在大量classLoader和大量反射类的情况其实也不多。
解决：