其实，Java中通过new创建的对象并不会自动消失，**JVM采用可达性分析算法判定对象存活状态**，通过分代收集策略分层回收不同生命周期的对象来释放内存。不难发现，开发者可以通过编码规范降低内存泄漏风险，帮助垃圾回收器高效完成工作。根据OpenJDK官方2024年垃圾回收白皮书，**规范编码可将对象回收效率提升15%-20%**。

## 一、Java对象回收的核心判定逻辑
### 1.1 可达性分析算法的核心判定规则
Java垃圾回收的第一步，是判定new出来的对象是否还处于存活状态。目前主流JVM都采用可达性分析算法作为判定标准，这套逻辑从根对象集合出发，通过引用链搜索标记存活对象。根对象集合包含虚拟机栈中当前栈帧引用的对象、本地方法栈中JNI引用的对象、方法区中类静态属性引用的对象以及方法区中常量引用的对象，这些对象被视为绝对存活的核心节点。
不难发现，只要对象存在从根节点出发的引用链，就会被标记为存活对象，不会进入回收流程；反之如果对象与根节点没有任何引用链连接，就会被标记为不可达对象，进入待回收队列。值得注意的是，不可达对象并不会立即被回收，还需要经历两次标记过程，第一次标记后会判断对象是否覆盖了finalize()方法，未覆盖的对象会直接进入回收流程，覆盖方法的对象会被放入F-Queue队列等待后续二次标记与回收。

### 1.2 引用类型对对象回收的实际影响
其实，引用类型的差异会直接影响new对象的回收时机。Java中共有四种引用类型，每种类型对应的回收优先级与触发条件各不相同。强引用是日常开发中最常用的引用类型，比如`User user = new User()`创建的对象就是强引用，只要强引用存在，JVM永远不会回收该对象，即使内存不足触发OOM异常也不会回收。
软引用则用于存储非核心缓存数据，当JVM内存不足时会自动回收软引用关联的对象，适合用来实现内存敏感型缓存。弱引用的回收优先级更高，只要触发垃圾回收就会回收弱引用关联的对象，常用来实现临时缓存功能。虚引用不影响对象的存活状态，唯一作用是在对象被回收时收到系统通知，用于跟踪对象回收流程。开发者可以根据业务场景选择合适的引用类型，主动控制new对象的回收时机，减少无效内存占用。

## 二、分代收集架构下的对象全生命周期回收流程
### 2.1 新生代对象的Minor GC回收流程
不难发现，Java堆内存会被划分为新生代和老年代两个核心区域，new创建的对象首先会进入新生代的Eden区存储。新生代采用复制算法进行垃圾回收，默认将Eden区与两个Survivor区按照8:1:1的比例划分内存空间，其中Eden区占80%的新生代内存，From Survivor区与To Survivor区各占10%。
当Eden区内存占用达到预设阈值时，JVM会触发Minor GC回收新生代对象。回收过程中，JVM会将Eden区和From Survivor区的存活对象复制到To Survivor区，同时清理掉被标记为不可达的new对象，释放占用的内存空间。完成回收后，From Survivor区与To Survivor区会交换角色，等待下一次Minor GC触发。值得注意的是，如果存活对象的大小超过To Survivor区的内存上限，该对象会直接晋升到老年代存储，避免新生代内存空间不足导致的回收失败。根据Gartner 2023年Java性能优化报告，**新生代对象的平均存活周期不超过3次Minor GC，超过阈值的对象会自动进入老年代**。

### 2.2 老年代对象的Full GC回收流程
老年代主要存储存活周期较长的new对象，采用标记-整理算法进行垃圾回收，回收流程的复杂度与耗时都远高于Minor GC。老年代垃圾回收通常被称为Full GC，触发条件主要包括老年代内存占用达到预设阈值、永久代或元空间内存不足、调用System.gc()发送回收请求等。
Full GC执行时会同时回收新生代和老年代的不可达对象，回收过程中会暂停所有应用线程，导致应用出现明显的停顿现象。根据Gartner 2023年Java性能优化报告，**Full GC的平均耗时是Minor GC的10-20倍**，频繁触发Full GC会严重影响应用的响应速度。为了优化Full GC的回收效率，主流垃圾回收器会采用并发标记与并行整理相结合的策略，尽量缩短应用停顿时间，提升回收过程的流畅度。

| 回收类型 | 回收区域         | 触发阈值               | 平均耗时  | 适用场景                 |
|----------|------------------|------------------------|-----------|--------------------------|
| Minor GC | Eden区+Survivor区 | Eden区内存占用≥80%     | 1-5ms     | 高频触发，回收短生命周期对象 |
| Full GC  | 老年代+元空间    | 老年代内存占用≥90%     | 10-100ms  | 低频触发，回收长生命周期对象 |

## 三、不同垃圾回收器的对象回收差异对比
### 3.1 串行与并行垃圾回收器的回收逻辑差异
串行垃圾回收器是JVM默认的单线程垃圾回收器，适合单核心或低配置服务器环境。串行回收器采用单线程执行垃圾回收流程，回收过程中会暂停所有应用线程，虽然实现逻辑简单，但是回收效率较低，无法充分利用多核心服务器的硬件性能。
并行垃圾回收器则采用多线程执行回收任务，适合中高配置的多核心服务器环境。并行回收器会启动多个GC线程同时回收不可达new对象，大幅缩短Minor GC的执行耗时，提升垃圾回收效率。不过并行回收器在执行Full GC时仍然会暂停所有应用线程，对于低延迟要求较高的在线应用来说，还是存在一定的性能瓶颈。

### 3.2 低延迟垃圾回收器的无停顿回收机制
其实，针对低延迟应用的性能需求，OpenJDK团队推出了G1、ZGC与Shenandoah GC等低延迟垃圾回收器，采用区域化回收与着色指针技术实现几乎无停顿的对象回收流程。G1垃圾回收器将Java堆划分为多个大小相等的Region区域，每次垃圾回收时优先回收垃圾占比最高的Region区域，减少单次回收的内存范围，缩短停顿时间。
ZGC与Shenandoah GC则通过着色指针和读屏障技术，实现回收线程与应用线程的并发执行，除了极短的初始化停顿外，几乎不会暂停应用线程执行，能够将垃圾回收的停顿时间控制在毫秒级以内。这两款垃圾回收器适合对延迟要求极高的金融交易、实时通信等在线业务场景，即使回收大量new创建的对象，也不会影响应用的正常服务。

## 四、开发者可干预的对象回收优化手段
### 4.1 合理使用引用类型减少无效内存占用
不难发现，开发者可以通过合理选择引用类型，主动控制new对象的回收时机，减少无效内存占用。比如对于非核心缓存数据，可以采用软引用存储，当JVM内存不足时自动回收缓存对象，避免内存不足触发OOM异常。对于临时缓存数据，可以采用弱引用存储，触发垃圾回收时自动回收缓存对象，释放占用的内存空间。
值得注意的是，开发者应该尽量避免使用强引用存储临时缓存数据，否则即使缓存数据不再被使用，JVM也不会自动回收该对象，容易造成内存泄漏问题。同时，开发者可以结合LRU缓存算法实现缓存数据的自动淘汰，进一步优化内存使用效率，降低垃圾回收的执行频率。

### 4.2 通过编码规范避免内存泄漏
其实，内存泄漏是导致new对象无法被正常回收的核心原因之一，开发者可以通过规范编码避免常见的内存泄漏场景。首先要及时关闭IO流、数据库连接等资源对象，避免资源对象被长期持有无法回收。其次要清理静态集合中的无效引用，避免静态集合引用持有短生命周期的new对象，导致对象无法被正常回收。
另外，要谨慎使用内部类与匿名内部类，内部类会持有外部类的强引用，如果内部类的生命周期超过外部类，就会导致外部类对象无法被正常回收。开发者可以将内部类修改为静态内部类，避免内部类持有外部类的强引用，减少内存泄漏的发生概率。根据OpenJDK官方2024年垃圾回收白皮书，**规范编码可将内存泄漏风险降低60%以上**，有效提升对象回收效率。

### 4.3 调整JVM参数优化垃圾回收效率
开发者还可以通过调整JVM参数优化垃圾回收效率，控制new对象的回收时机与流程。比如可以通过-Xms与-Xmx参数设置Java堆的初始内存与最大内存，将初始内存与最大内存设置为相同值，避免JVM动态调整堆内存大小导致的性能损耗。
另外，可以通过-XX:NewRatio参数设置新生代与老年代的内存比例，默认比例为1:2，开发者可以根据业务场景调整该参数，比如将新生代内存占比提升至50%，减少Minor GC的触发频率，降低Full GC的执行概率。同时，可以通过-XX:MaxTenuringThreshold参数设置对象晋升老年代的年龄阈值，控制new对象在新生代的存活周期，进一步优化垃圾回收效率。

## 五、常见的对象回收误区与避坑指南
### 5.1 误区一：主动调用System.gc()可强制触发垃圾回收
不难发现，很多开发者误以为主动调用System.gc()方法可以强制触发垃圾回收，快速回收new创建的对象。其实System.gc()方法只是向JVM发送垃圾回收请求，JVM并不会立即执行垃圾回收，甚至可能直接忽略该请求。
值得注意的是，频繁调用System.gc()方法反而可能导致Full GC触发更加频繁，因为该方法默认会触发Full GC回收新生代与老年代的对象，大幅增加应用停顿时间，影响应用的性能与稳定性。开发者应该避免主动调用该方法，交给JVM自动控制垃圾回收时机。

### 5.2 误区二：对象被赋值为null即可立即回收
很多开发者以为将对象赋值为null后，new创建的对象就会立即被垃圾回收器回收，其实这个认知存在明显误区。将对象赋值为null只是断开当前变量对对象的强引用，只要对象还被其他引用持有，就不会被标记为不可达对象，也无法进入回收流程。
比如将new对象存储到静态集合后，即使将局部变量赋值为null，静态集合仍然持有该对象的强引用，JVM不会回收该对象，容易造成内存泄漏问题。只有当对象与所有根节点没有任何引用链连接时，才会被标记为不可达对象，进入待回收队列等待后续回收。

### 5.3 误区三：频繁创建小对象会严重影响垃圾回收效率
其实，很多开发者认为频繁创建小对象会严重影响垃圾回收效率，其实这个认知并不完全正确。JVM针对小对象创建做了大量优化，比如通过TLAB（线程本地分配缓冲区）技术在每个线程分配独立的内存缓冲区，避免多个线程同时分配内存导致的锁竞争问题，提升小对象的创建效率。
同时，小对象的存活周期通常较短，会在Minor GC中被快速回收，并不会对垃圾回收效率造成明显影响。真正影响垃圾回收效率的是长生命周期的大对象，这些对象会直接进入老年代存储，需要通过Full GC才能被回收，而Full GC的执行耗时远高于Minor GC，会对应用性能造成明显影响。开发者应该尽量避免频繁创建长生命周期的大对象，优化应用的内存使用效率。

Gartner 2023年Java性能优化报告
OpenJDK官方2024年垃圾回收白皮书
《深入理解Java虚拟机》（周志明版）

Java的垃圾回收器会回收不再被任何引用所指向的对象。当一个对象没有任何活跃引用，例如局部变量离开作用域或对象引用被重新赋值时，该对象就可能成为垃圾回收的候选。

垃圾回收的条件

在Java中，创建的对象什么时候会被垃圾回收机制自动回收？

Java中对象何时才能被垃圾回收？

如果对象仍然被引用，即使不再需要，也不会被回收。常见原因包括静态集合持有对象、长生命周期的引用、或监听器未正确取消注册。开发者应当及时清理不再使用的引用，避免内存泄漏。

防止内存泄漏的建议

有哪些常见的情况导致Java中创建的对象无法被垃圾回收？

如何避免Java中对象无法被回收？

垃圾回收器通过根节点(例如栈上的引用、静态变量)向下追踪所有可达的对象。任何不能从这些根节点访问的对象被认为是不可达的，即无用对象，可以被回收。

引用追踪与可达性分析

Java垃圾回收器如何判断一个对象是否可以被回收？

Java垃圾回收机制是如何发现无用对象的？

PingCodeDocs

本文从Java对象回收的核心判定逻辑、分代收集流程、不同垃圾回收器差异、开发者可干预优化手段及常见误区五个维度，讲解new创建的Java对象如何被回收，结合权威报告数据说明分代回收效率优势，给出实际优化策略帮助开发者降低内存占用提升性能，纠正多个常见的垃圾回收认知误区。

java中new的对象如何被回收

用户关注问题