网站内链的作用疫情最新动态

🧑 博主简介：CSDN博客专家，历代文学网（PC端可以访问：https://literature.sinhy.com/#/?__c=1000，移动端可微信小程序搜索“历代文学”）总架构师，15年工作经验，精通Java编程，高并发设计，Springboot和微服务，熟悉Linux，ESXI虚拟化以及云原生Docker和K8s，热衷于探索科技的边界，并将理论知识转化为实际应用。保持对新技术的好奇心，乐于分享所学，希望通过我的实践经历和见解，启发他人的创新思维。在这里，我希望能与志同道合的朋友交流探讨，共同进步，一起在技术的世界里不断学习成长。
技术合作请加本人wx（注明来自csdn）：foreast_sea

---

1. 对象一定分配在堆中吗？有没有了解逃逸分析技术？

在 Java 中，并不是所有对象都严格在堆上分配内存，虽然堆（Heap）是 Java 对象内存分配的主要区域。

在某些情况下，JVM 的即时编译器（JIT）可能会将对象分配在栈上，这被称为逃逸分析（Escape Analysis）。

也就是说，如果编译器确定一个对象不会在方法外部使用（即对象不会逃逸出方法的作用域），那么该对象可以分配在栈上，而不是堆上。

什么是逃逸分析？

逃逸分析是指分析指针动态范围的方法，它同编译器优化原理的指针分析和外形分析相关联。当变量（或者对象）在方法中分配后，其指针有可能被返回或者被全局引用，这样就会被其他方法或者线程所引用，这种现象称作指针（或者引用）的逃逸(Escape)。

通俗点讲，当一个对象被 new 出来之后，它可能被外部所调用，如果是作为参数传递到外部了，就称之为方法逃逸。

除此之外，如果对象还有可能被外部线程访问到，例如赋值给可以在其它线程中访问的实例变量，这种就被称为线程逃逸。

逃逸分析有什么好处？

• 栈上分配

如果确定一个对象不会逃逸到线程之外，那么久可以考虑将这个对象在栈上分配，对象占用的内存随着栈帧出栈而销毁，这样一来，垃圾收集的压力就降低很多。

• 同步消除

线程同步本身是一个相对耗时的过程，如果逃逸分析能够确定一个变量不会逃逸出线程，无法被其他线程访问，那么这个变量的读写肯定就不会有竞争， 对这个变量实施的同步措施也就可以安全地消除掉。

• 标量替换

如果一个数据是基本数据类型，不可拆分，它就被称之为标量。把一个 Java 对象拆散，将其用到的成员变量恢复为原始类型来访问，这个过程就称为标量替换。假如逃逸分析能够证明一个对象不会被方法外部访问，并且这个对象可以被拆散，那么可以不创建对象，直接用创建若干个成员变量代替，可以让对象的成员变量在栈上分配和读写。

2. 内存溢出和内存泄漏是什么意思？

内存溢出，俗称 OOM，是指当程序请求分配内存时，由于没有足够的内存空间满足其需求，从而触发的错误。在 Java 中，这种情况会抛出 OutOfMemoryError。

内存溢出可能是由于内存泄漏导致的，也可能是因为程序一次性尝试分配大量内存，内存直接就干崩溃了导致的。

内存泄漏是指程序在使用完内存后，未能释放已分配的内存空间，导致这部分内存无法再被使用。随着时间的推移，内存泄漏会导致可用内存逐渐减少，最终可能导致内存溢出。

在 Java 中，内存泄漏通常发生在长期存活的对象持有短期存活对象的引用，而长期存活的对象又没有及时释放对短期存活对象的引用，从而导致短期存活对象无法被回收。

用一个比较有味道的比喻来形容就是，内存溢出是排队去蹲坑，发现没坑了；内存泄漏，就是有人占着茅坑不拉屎，占着茅坑不拉屎的多了可能会导致坑位不够用。

3. 能手写内存溢出的例子吗？

导致内存溢出（OOM）的原因有很多，比如一次性创建了大量对象导致堆内存溢出；比如说元空间溢出，抛出 java.lang.OutOfMemoryError：Metaspace，比如说栈溢出，如果栈的深度超过了 JVM 栈所允许的深度，将会抛出 StackOverflowError。

堆内存溢出是最常见的 OOM 原因，通常是因为创建了大量的对象，且长时间无法被垃圾收集器回收，导致堆内存耗尽。

这就相当于一个房子里，不断堆积不能被回收的杂物，那么房子很快就会被堆满了。

来通过代码模拟一下堆内存溢出的情况。

public class HeapSpaceErrorGenerator {public static void main(String[] args) {List<byte[]> bigObjects = new ArrayList<>();try {while (true) {// 创建一个大约 10MB 的数组byte[] bigObject = new byte[10 * 1024 * 1024];bigObjects.add(bigObject);}} catch (OutOfMemoryError e) {System.out.println("OutOfMemoryError 发生在 " + bigObjects.size() + " 对象后");throw e;}}
}

通过 VM 参数设置堆内存大小为 -Xmx128M，然后运行程序。

可以看到，堆内存溢出发生在 11 个对象后。

4. 内存泄漏可能由哪些原因导致呢？

比如说：

①、静态的集合中添加的对象越来越多，但却没有及时清理；

public class OOM {static List list = new ArrayList();public void oomTests(){Object obj = new Object();list.add(obj);}
}

②、单例模式下对象持有的外部引用无法及时释放；

③、数据库、IO、Socket 等连接资源没有及时关闭；

try {Connection conn = null;Class.forName("com.mysql.jdbc.Driver");conn = DriverManager.getConnection("url", "", "");Statement stmt = conn.createStatement();ResultSet rs = stmt.executeQuery("....");} catch (Exception e) {}finally {//不关闭连接}

④、变量的作用域不合理；

class Simple {Object object;public void method1(){object = new Object();//...其他代码//由于作用域原因，method1执行完成之后，object 对象所分配的内存不会马上释放}
}

⑤、hash 值发生变化但对象却没有改变，这也是为什么 String 被设计成不可变对象的原因之一，就是因为假如 String 的哈希值发生了改变，但对应的值没变，就导致 HashMap 中的对象无法被及时清理；

⑥、使用完 ThreadLocal 没有使用 remove 方法来进行清除。

5. 有没有处理过内存泄漏问题？是如何定位的？

有，内存泄漏是指程序在运行过程中由于未能正确释放已分配的内存，导致内存无法被重用，从而引发内存耗尽等问题。

当时在做技术派项目的时候，由于 ThreadLocal 没有及时清理导致出现了内存泄漏问题。

常用的可视化监控工具有 JConsole、VisualVM、JProfiler、Eclipse Memory Analyzer (MAT)等。

也可以使用 JDK 自带的 jmap、jstack、jstat 等命令行工具来配合内存泄露问题的排查。

严重的内存泄漏往往伴随频繁的 Full GC，所以排查内存泄漏问题时，可以从 Full GC 入手。

第一步，使用 jps -l 查看运行的 Java 进程 ID。

第二步，使用top -p [pid] 查看进程使用 CPU 和内存占用情况。

第三步，使用 top -Hp [pid] 查看进程下的所有线程占用 CPU 和内存情况。

第四步，抓取线程栈：jstack -F 29452 > 29452.txt，可以多抓几次做个对比。

29452 为 pid，顺带作为文件名。

看看有没有线程死锁、死循环或长时间等待这些问题。

第五步，可以使用jstat -gcutil [pid] 5000 10 每隔 5 秒输出 GC 信息，输出 10 次，查看 YGC 和 Full GC 次数。

通常会出现 YGC 不增加或增加缓慢，而 Full GC 增加很快。

或使用 jstat -gccause [pid] 5000 输出 GC 摘要信息。

或使用 jmap -heap [pid] 查看堆的摘要信息，关注老年代内存使用是否达到阀值，若达到阀值就会执行 Full GC。

如果发现 Full GC 次数太多，就很大概率存在内存泄漏了。

第六步，生成 dump 文件，然后借助可视化工具分析哪个对象非常多，基本就能定位到问题根源了。

执行命令 jmap -dump:format=b,file=heap.hprof 10025 会输出进程 10025 的堆快照信息，保存到文件 heap.hprof 中。

第七步，可以使用图形化工具分析，如 JDK 自带的 VisualVM，从菜单 > 文件 > 装入 dump 文件。

然后在结果观察内存占用最多的对象，找到内存泄漏的源头。

6. 有没有处理过内存溢出问题？

有，内存溢出，也就是 Out of Memory，是指当程序请求分配内存时，由于没有足够的内存空间满足其需求，从而触发的错误。

当时在做技术派的时候，由于上传的文件过大，没有正确处理，导致一下子撑爆了内存，程序直接崩溃了。

当发生 OOM 时，可以导出堆转储（Heap Dump）文件进行分析。如果 JVM 还在运行，可以使用 jmap 命令手动生成 Heap Dump 文件：

jmap -dump:format=b,file=heap.hprof <pid>

生成 Heap Dump 文件后，可以使用 MAT、JProfiler 等工具进行分析，查看内存中的对象占用情况，找到内存泄漏的原因。

如果生产环境的内存还有很多空余，可以适当增大堆内存大小，例如 -Xmx4g 参数。

或者检查代码中是否存在内存泄漏，如未关闭的资源、长生命周期的对象等。

之后，我会在本地进行压力测试，模拟高负载情况下的内存表现，确保修改有效，且没有引入新的问题。

7. 什么情况下会发生栈溢出？（补充）

栈溢出（StackOverflowError）发生在程序调用栈的深度超过 JVM 允许的最大深度时。栈溢出的本质是因为线程的栈空间不足，导致无法再为新的栈帧分配内存。

当一个方法被调用时，JVM 会在栈中分配一个栈帧，用于存储该方法的执行信息。如果方法调用嵌套太深，栈帧不断压入栈中，最终会导致栈空间耗尽，抛出 StackOverflowError。

最常见的栈溢出场景是递归调用，尤其是没有正确的终止条件，导致递归无限进行。

class StackOverflowExample {public static void recursiveMethod() {// 没有终止条件的递归调用recursiveMethod();}public static void main(String[] args) {recursiveMethod();  // 导致栈溢出}
}

另外，如果方法中定义了特别大的局部变量，栈帧会变得很大，导致栈空间更容易耗尽。

public class LargeLocalVariables {public static void method() {int[] largeArray = new int[1000000];  // 大量局部变量method();  // 递归调用}public static void main(String[] args) {method();  // 导致栈溢出}
}