今天，测试同学突然反应：“某 JAVA 服务内存占用太高，GC 后也没释放，内存只增不减，是不是内存泄漏了！”
然后我赶紧看了下，一切正常，FULL GC 一次没有，YoungGC，十分钟一次，堆空闲也很充足。
QA：“你们这个服务现在堆内存 used 才 800M，但这个 JAVA 进程已经占了 6G 内存了，是不是你们程序出啥内存泄露的 bug 了！”
我想都没想，直接回了一句：“不可能，我们服务非常稳定，不会有这种问题！”
不过说完之后，内心还是自我质疑了一下：会不会真有什么bug？难道是堆外泄露？线程没销毁？导致内存泄露了？？？
然后我很“镇定”的补了一句：“我先上服务器看看啥情况”，被打脸可就不好了，还是不要装太满的好……
迅速上登上服务器又仔细的查看了各种指标，Heap/GC/Thread/Process 之类的，发现一切正常，并没有什么“泄漏”的迹象。
QA：你看你们这个 JAVA 服务，堆现在 used 才 400MB，但这个进程现在内存占用都 6G 了，还说没问题？肯定是内存泄露了，锅接好，赶紧回去查问题吧
然后我指着监控信息，让QA看：“大哥你看这监控历史，堆内存是达到过 6G 的，只是后面 GC 了，没问题啊！”
QA：“回收了你这内存也没释放啊，你看这个进程 Res 还是 6G，肯定有问题啊”
我心想这运QA同学是不是个der，JVM GC 回收和进程内存又不是一回事，不过还是和得他解释一下，不然一直baba个没完
“JVM 的垃圾回收，只是一个
逻辑上的回收，回收的只是 JVM 申请的那一块逻辑堆区域，将数据标记为空闲之类的操作，不是调用 free 将内存归还给操作系统”QA顿了两秒后，突然脸色一转，开始笑起来：“咳咳，我可能没注意这个。你再给我讲讲 JVM 的这个内存管理/回收和进程上内存的关系呗”
虽然我内心是拒绝的，但得罪谁也不能得罪QA啊，不然给你提一堆bug，想想还是给大哥解释解释，“增进下感情”
操作系统 与 JVM的内存分配
JVM 的自动内存管理，其实只是先向操作系统申请了一大块内存，然后自己在这块已申请的内存区域中进行“自动内存管理”。JAVA 中的对象在创建前，会先从这块申请的一大块内存中划分出一部分来给这个对象使用，在 GC 时也只是这个对象所处的内存区域数据清空，标记为空闲而已
运维：“原来是这样，那按你的意思，JVM 就不会将 GC 回收后的空闲内存还给操作系统了吗？”
为什么不把内存归还给操作系统？
JVM 还是会归还内存给操作系统的，只是因为这个代价比较大，所以不会轻易进行。而且不同垃圾回收器 的内存分配算法不同，归还内存的代价也不同。
比如在清除算法（sweep）中，是通过空闲链表（free-list）算法来分配内存的。简单的说就是将已申请的大块内存区域分为 N 个小区域，将这些区域同链表的结构组织起来，就像这样：
每个 data 区域可以容纳 N 个对象，那么当一次 GC 后，某些对象会被回收，可是此时这个 data 区域中还有其他存活的对象，如果想将整个 data 区域释放那是肯定不行的。
所以这个归还内存给操作系统的操作并没有那么简单，执行起来代价过高，JVM 自然不会在每次 GC 后都进行内存的归还。
怎么归还？
虽然代价高，但 JVM 还是提供了这个归还内存的功能。JVM 提供了-XX:MinHeapFreeRatio和-XX:MaxHeapFreeRatio 两个参数，用于配置这个归还策略。
- MinHeapFreeRatio 代表当空闲区域大小下降到该值时，会进行扩容，扩容的上限为
Xmx - MaxHeapFreeRatio 代表当空闲区域超过该值时，会进行“缩容”，缩容的下限为
Xms
不过虽然有这个归还的功能，不过因为这个代价比较昂贵，所以 JVM 在归还的时候，是线性递增归还的，并不是一次全部归还。
但是但是但是，经过实测，这个归还内存的机制，在不同的垃圾回收器，甚至不同的 JDK 版本中还不一样！
不同版本&垃圾回收器下的表现不同
下面是之前跑过的测试结果：
public static void main(String[] args) throws IOException, InterruptedException {
List<Object> dataList = new ArrayList<>();
for (int i = 0; i < 25; i++) {
byte[] data = createData(1024 * 1024 * 40);// 40 MB
dataList.add(data);
}
Thread.sleep(10000);
dataList = null; // 待会 GC 直接回收
for (int i = 0; i < 100; i++) {
// 测试多次 GC
System.gc();
Thread.sleep(1000);
}
System.in.read();
}
public static byte[] createData(int size){
byte[] data = new byte[size];
for (int i = 0; i < size; i++) {
data[i] = Byte.MAX_VALUE;
}
return data;
}| JAVA 版本 | 垃圾回收器 | VM Options | 是否可以“归还” |
|---|---|---|---|
| JAVA 8 | UseParallelGC(ParallerGC + ParallerOld) | -Xms100M -Xmx2G -XX:MaxHeapFreeRatio=40 | 否 |
| JAVA 8 | CMS+ParNew | -Xms100M -Xmx2G -XX:MaxHeapFreeRatio=40 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC | 是 |
| JAVA 8 | UseG1GC(G1) | -Xms100M -Xmx2G -XX:MaxHeapFreeRatio=40 -XX:+UseG1GC | 是 |
| JAVA 11 | UseG1GC(G1) | -Xms100M -Xmx2G -XX:MaxHeapFreeRatio=40 | 是 |
| JAVA 16 | UseZGC(ZGC) | -Xms100M -Xmx2G -XX:MaxHeapFreeRatio=40 -XX:+UseZGC | 否 |
如何分析Java服务是否真的存在内存泄漏
下面通过实例来分析讲解：
上面只是解释了，JVM内存使用的机制，如果Java服务真的发生内存泄漏，我们该怎么分析呢：
如何确定Java服务所需的内存量。首先，让我们来了解整个过程的步骤。
流程步骤
下表展示了确定Java服务所需内存的步骤：
步骤1：分析Java服务的需求和特性
在开始配置Java服务的内存之前，我们需要了解Java服务的需求和特性。这包括并发用户数、数据量、使用的框架和库等。根据这些信息，我们可以对Java服务的内存需求有一个基本的了解。
步骤2：确定Java虚拟机（JVM）的堆内存大小
Java虚拟机的堆内存是Java服务的主要内存部分，它用于存储对象实例和数组。我们可以通过设置JVM的-Xmx参数来指定堆内存的最大大小。通常情况下，我们可以根据Java服务的需求来确定合适的堆内存大小。
下面是一个示例代码，用于设置JVM的堆内存大小为2GB：
java -Xmx2g YourJavaService步骤3：设置初始堆内存和最大堆内存的大小
除了设置堆内存的最大大小外，我们还需要设置初始堆内存的大小。可以通过设置JVM的-Xms参数来指定初始堆内存的大小。通常情况下，初始堆内存的大小可以设置为与最大堆内存大小相同，以避免堆内存的频繁扩容。
下面是一个示例代码，用于设置JVM的初始堆内存和最大堆内存大小为2GB：
java -Xms2g -Xmx2g YourJavaService步骤4：监控Java服务的内存使用情况
在Java服务运行期间，我们需要监控其内存使用情况，以便进行调整和优化。可以使用Java管理扩展（JMX）或其他监控工具来获取Java服务的内存使用情况。
下面是一个示例代码，用于使用JMX监控Java服务的内存使用情况：
// 导入相关的JMX类
import java.lang.management.ManagementFactory;
import javax.management.MBeanServer;
import javax.management.ObjectName;
// 创建MBeanServer实例
MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
// 创建ObjectName实例，用于指定要监控的MBean
ObjectName name = new ObjectName("java.lang:type=Memory");
// 获取并打印Java服务的堆内存使用情况
long heapMemoryUsage = (long) mbs.getAttribute(name, "HeapMemoryUsage");
System.out.println("Heap Memory Usage: " + heapMemoryUsage);步骤5：定期进行性能测试和负载测试
为了确保Java服务的内存配置合理，我们需要定期进行性能测试和负载测试。这将帮助我们发现潜在的内存问题，并优化Java服务的性能。
下面是一个示例代码，用于进行性能测试和负载测试：
// 导入相关的测试框架和库
import org.junit.Test;
import static org.junit.Assert.*;
// 编写性能测试和负载测试的测试用例
public class YourJavaServiceTest {
@Test
public内存管理的常见问题与解决方案
| 区域 | 线程关系 | 内存异常 | 垃圾回收 | 作用 |
|---|---|---|---|---|
| 程序计数器 | 线程私有 | 无 | 无 | 记录 Java 虚拟机正在指向的字节码指令 |
| Java虚拟机栈 | 线程私有 | StackOverflowError、OutOfMemoryError | 无 | 描述 Java 方法执行时的内存模型，栈中栈帧存储局部变量表、操作数栈、动态链接、方法返回地址等信息 |
| 本地方法栈 | 线程私有 | StackOverflowError、OutOfMemoryError | 无 | 描述本地方法（非 Java 代码编写）执行时的内存模型 |
| 方法区 | 线程共享 | OutOfMemoryError | 有 | 存储虚拟机加载过的类信息、常量（常量池）、静态变量、即时编译器（JIT）生成的代码 |
| Java 堆 | 线程共享 | OutOfMemoryError | 有 | 存放 Java 对象（实例） |
（一）内存泄漏
- 原因：在 Java 中，内存泄漏指的是程序中已不再使用的对象，却因仍然被引用而无法被垃圾回收器回收，导致内存占用不断增加，最终可能引发内存溢出。其常见原因包括：
- ）静态集合类持有对象引用，像HashMap、ArrayList等静态集合类，若未及时移除不再需要的对象，就会使这些对象无法被回收；
- ）未关闭的资源，如文件、数据库连接、网络连接等，若不及时关闭，相关对象无法被回收；
- ）内部类和匿名类持有外部类引用，导致外部类无法被回收；
- ）缓存设计不当，缓存对象未及时清除，也会造成内存泄漏。
- 常见场景：比如在一个 Web 应用中，使用静态HashMap来缓存用户信息，随着用户数量的增加，HashMap中的数据不断增多，却没有清理机制，即使部分用户已经注销，其信息仍在HashMap中占用内存，从而导致内存泄漏 。又比如在数据库操作中，若没有正确关闭Connection、Statement和ResultSet，每次操作后这些对象都会占用内存，随着操作次数的增加，内存占用也会不断上升。
- 检测方法：可以使用内存分析工具，如jvisualvm、Eclipse MAT（Memory Analyzer Tool）等。以jvisualvm为例，启动它并选择要监控的 Java 应用程序，在 “Monitor” 选项卡中观察内存使用情况，若发现内存使用量持续增长且没有明显的下降趋势，就可能存在内存泄漏；在 “Heap Dump” 选项卡中生成堆转储文件，通过分析对象引用，找出持有大量对象引用且未被释放的地方 。还可以通过代码审查，定期检查代码中是否存在静态集合类不合理使用、资源未及时关闭、内部类和匿名类导致外部类无法回收以及缓存设计不合理等问题。
- 避免建议和代码优化方案：
- ）尽量减少静态变量的使用，若必须使用，要格外小心，及时从静态集合中删除不再需要的数据；
- ）确保在对象不再使用时，将其引用设置为null，帮助垃圾回收器及时回收内存；
- ）使用try - with - resources语句确保资源（如文件、数据库连接等）能被自动关闭；
- ）对于缓存，考虑使用WeakHashMap，当除了自身对key的引用外，key没有其他引用时，WeakHashMap会自动丢弃该值；在不再需要监听器或回调时，及时将其移除。以下是一个使用WeakHashMap优化缓存的示例代码：
import java.util.Map; import java.util.WeakHashMap; public class CacheExample { private static final Map<Integer, String> cache = new WeakHashMap<>(); public void addToCache(int id, String value) { cache.put(id, value); } public static void main(String[] args) { CacheExample cacheExample = new CacheExample(); for (int i = 0; i < 100000; i++) { cacheExample.addToCache(i, "value" + i); } } }
（二）内存溢出
- 原因：内存溢出是指应用系统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于虚拟机能提供的最大内存。其常见原因包括：
- ）内存中加载的数据量过于庞大，如一次从数据库取出过多数据；
- ）集合类中有对对象的引用，使用完后未清空，使得 JVM 不能回收；
- ）代码中存在死循环或循环产生过多重复的对象实体；
- ）使用的第三方软件中的 BUG；
- ）启动参数内存值设定过小。
- 常见类型：常见的内存溢出类型有：
- ）Java 堆内存溢出，当不断创建对象且对象无法被回收，导致 Java 堆无法再分配内存时，会抛出OutOfMemoryError: Java heap space异常；
- ）方法区内存溢出，在 JDK 8 之前，表现为OutOfMemoryError: PermGen space，JDK 8 及之后为OutOfMemoryError: Metaspace，通常是由于大量类被加载，方法区无法容纳更多的类信息、常量、静态变量等导致；
- ）虚拟机栈溢出，当线程请求的栈深度超过虚拟机所允许的最大深度，会抛出StackOverflowError异常，或者虚拟机栈动态扩展时无法申请到足够的内存，抛出OutOfMemoryError: unable to create new native thread异常 。
- 解决方法：
- ）首先，修改 JVM 启动参数，直接增加内存，如通过-Xms设置初始堆大小，-Xmx设置最大堆大小，-XX:MaxMetaspaceSize设置元空间的最大值等；
- ）然后，检查错误日志，查看 “OutOfMemory” 错误前是否有其它异常或错误，以便定位问题；
- ）最后，对代码进行走查和分析，找出可能发生内存溢出的位置，如是否存在大量对象创建且未释放、是否有不合理的递归调用等。
- 调整 JVM 参数的作用：调整 JVM 参数可以有效地解决内存溢出问题。例如，增大-Xmx的值可以增加 Java 堆的最大可用内存，使程序有更多的内存空间来分配对象；合理设置-XX:MaxMetaspaceSize可以控制元空间的大小，避免因类加载过多导致元空间溢出；通过调整-Xss参数可以设置每个线程的栈大小，从而影响虚拟机栈的内存分配，避免栈溢出。但需要注意的是，JVM 参数的调整需要根据实际应用场景和服务器硬件配置进行合理设置，并非越大越好，否则可能会导致其他性能问题。
（三）频繁垃圾回收
- 原因：频繁垃圾回收的原因主要有：
- ）堆内存大小设置不合理，若堆内存过小，对象很快就会填满堆空间，导致频繁触发垃圾回收；
- ）新生代与老年代的比例设置不当，若新生代过小，存活对象会频繁晋升到老年代，增加老年代的压力，导致频繁的 Full GC；
- ）对象创建过于频繁，在短时间内创建大量的对象，超出了垃圾回收器的处理能力，也会导致频繁垃圾回收；
- ）此外，垃圾回收器的选择和配置不合适，也可能导致垃圾回收效率低下，从而频繁触发。
- 对程序性能的影响：频繁垃圾回收会占用大量的 CPU 时间，导致应用程序可用的 CPU 资源减少，从而降低系统的吞吐量；在垃圾回收过程中，通常需要暂停应用程序线程（即 “Stop The World”），频繁的暂停会使应用程序的响应时间变长，影响用户体验；频繁的垃圾回收还可能导致内存抖动，即内存的使用情况频繁波动，这会增加系统的不稳定因素，进一步影响程序性能。
- 优化建议和方法：
- ）可以根据应用程序的实际内存需求，合理调整堆大小，通过设置-Xms和-Xmx参数，确保堆内存既不会过小导致频繁垃圾回收，也不会过大浪费系统资源；
- ）根据对象的生命周期特点，合理调整新生代和老年代的比例，例如，对于对象存活时间较短的应用，可以适当增大新生代的大小，减少对象晋升到老年代的频率；
- ）采用对象池、复用对象等技术，减少对象的创建次数，降低垃圾回收的压力；
- ）选择合适的垃圾回收器，并根据应用场景进行合理配置，如对于对响应时间要求较高的应用，可以选择 CMS 或 G1 垃圾回收器，并调整相应的参数，如设置-XX:MaxGCPauseMillis来控制最大垃圾回收停顿时间；
- ）通过监控工具（如jstat、jvisualvm等）实时监控垃圾回收情况，分析 GC 日志，了解垃圾回收的频率、停顿时间等信息，根据分析结果进行针对性的优化。
总结一下
对于大多数服务端场景来说，并不需要JVM 这个手动释放内存的操作。至于 JVM 是否归还内存给操作系统这个问题，我们也并不关心。而且基于上面那个测试结果，不同 JAVA 版本，不同垃圾回收器版本区别这么大，更是没必要去深究了。
综上，JVM 虽然可以释放空闲内存给操作系统，但是不一定会释放，在不同 JAVA 版本，不同垃圾回收器版本下表现不同，知道有这个机制就行。
扫一扫
629
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
