写面经主要是为了总结、方便后面学习，AI回答的不一定全面、全对，但面试官问的问题就是这些。

以下是AI解答！

Redis核心原理全解析

Redis（Remote Dictionary Server）是一个开源、高性能、基于内存的键值对数据库，同时支持持久化、高可用和分布式集群部署。其核心优势在于极致性能（QPS可达10万+）和丰富的数据结构，广泛用于缓存、消息队列、分布式锁、排行榜等场景。

一、核心架构：单线程事件驱动模型

1. 单线程设计

• Redis主线程采用单线程处理所有客户端请求，避免了多线程上下文切换和锁竞争的开销
• 单线程不影响性能的原因：

• 所有数据操作在内存中完成，避免磁盘IO瓶颈
• 通过I/O多路复用处理大量并发连接，而非阻塞式I/O
• 命令执行时间短，无长时间阻塞操作（如复杂计算、网络请求）

2. 事件驱动机制

Redis核心是aeEventLoop（事件循环），持续监听两类事件：

工作流程：

1. 主线程通过epoll_wait()等待就绪事件
2. 依次处理就绪事件（先文件事件，后时间事件）
3. 循环往复，高效处理大量并发请求

二、底层数据结构实现

Redis支持多种数据类型，每种类型都有对应的底层优化实现，平衡性能与内存占用。

1. 基础数据结构

2. 关键结构详解

• SDS（Simple Dynamic String）：Redis自定义字符串结构，解决C字符串缺陷

struct sdshdr {
  int len;    // 已用长度（不含'\0'）
  int free;   // 空闲长度
  char buf[]; // 字符数组
};

• 优势：O(1)获取长度、杜绝缓冲区溢出、减少内存重分配次数、二进制安全

• QuickList：结合双向链表和压缩列表的优势

• 链表节点是压缩列表，减少内存碎片
• 支持快速插入/删除，同时节省内存空间

• Skiplist（跳表）：Sorted Set的核心结构

• 多层索引结构，支持O(logN)时间复杂度的查找、插入、删除
• 比平衡树实现更简单，无需复杂的旋转操作

三、持久化机制

Redis支持三种持久化方式，防止内存数据丢失。

1. RDB（Redis Database File）

• 原理：按指定时间间隔生成数据集的快照，保存到磁盘文件（dump.rdb）
• 触发方式：

• 手动执行SAVE（阻塞）或BGSAVE（后台异步，fork子进程）
• 配置自动触发：save 900 1（900秒内至少1个键变更）

• 优势：文件小、恢复速度快
• 劣势：可能丢失最后一次快照后的所有数据，fork子进程可能影响性能

2. AOF（Append Only File）

• 原理：记录所有写命令到日志文件（appendonly.aof），重启时重新执行命令恢复数据
• 三种同步策略：

• appendfsync always：每次命令立即同步（最安全，性能最差）
• appendfsync everysec：每秒同步（默认，平衡安全与性能）
• appendfsync no：由操作系统决定同步时机（性能最好，最不安全）

• 重写机制：BGREWRITEAOF合并重复命令，减小文件体积
• 优势：数据安全性高，最多丢失1秒数据
• 劣势：文件体积大，恢复速度慢

3. 混合持久化（Redis 4.0+）

• 原理：RDB快照 + AOF增量命令的组合，兼顾两者优势
• 过程：重写AOF时，先写入RDB数据，再追加增量命令
• 优势：恢复速度快（RDB）+ 数据安全性高（AOF）

四、内存管理机制

Redis高效管理内存的核心机制，防止内存溢出和碎片问题。

1. 过期键删除策略

Redis采用惰性删除+定期删除协同工作，平衡性能与实时性：

实现细节：

• 过期时间存储在expires字典中（key为指针，value为过期时间戳）
• 定期删除每次检查20个键，删除过期键，若过期率>25%则重复执行，限制最大执行时间（默认25ms），避免阻塞主线程

2. 内存淘汰策略（maxmemory限制）

当内存使用量超过maxmemory时，Redis触发淘汰策略清理数据：

注意：Redis使用近似LRU/LFU算法（非严格实现），通过24bit的lru/lfu字段记录访问信息，减少性能开销。

3. 内存优化技术

• jemalloc内存分配器：高效管理内存，减少碎片
• 对象共享：小整数（0-9999）和常用字符串共享同一对象，减少内存占用
• 主动碎片整理：通过active-defrag配置，后台整理内存碎片

五、事务与Lua脚本

1. Redis事务

Redis事务通过MULTI-EXEC实现，保证命令的原子性（要么全部执行，要么全部不执行）：

MULTI          # 开启事务
SET key1 value1
SET key2 value2
EXEC           # 执行事务

• 特性：

• 事务中命令入队，EXEC时批量执行
• 不支持回滚（错误命令会被忽略，不会影响其他命令执行）
• 执行过程中不会被其他客户端命令打断

2. Lua脚本

• 原理：Redis内置Lua解释器，支持原子执行复杂逻辑
• 优势：

• 原子性：脚本执行期间不中断，避免竞态条件
• 减少网络开销：一次传输多个命令逻辑
• 可扩展性：自定义复杂操作

• 示例：

EVAL "return redis.call('SET', KEYS[1], ARGV[1])" 1 mykey myvalue

六、高可用与集群机制

1. 主从复制

• 原理：从节点复制主节点数据，实现读写分离和故障转移
• 复制过程：

1. 从节点发送SYNC命令请求全量同步
2. 主节点执行BGSAVE生成RDB文件，同时记录增量命令
3. 主节点发送RDB文件和增量命令给从节点
4. 从节点加载RDB并执行增量命令，保持数据一致

• Redis 2.8+优化：支持部分重同步（通过复制偏移量和运行ID），网络中断后无需全量同步

2. Redis Sentinel（哨兵）

• 作用：监控主从节点状态，自动故障转移，提供高可用保障
• 核心功能：

• 节点健康检查：定期发送PING命令检测节点存活
• 自动故障转移：主节点宕机时，选举新主节点并通知所有从节点切换
• 配置提供者：客户端通过哨兵获取当前主节点地址

3. Redis Cluster（集群）

• 原理：数据分片存储，自动分区，无中心节点，支持水平扩展
• 数据分片：

• 采用哈希槽（hash slot）机制，共16384个槽位
• 每个节点负责部分槽位，通过CRC16(key) % 16384计算键所属槽位
• 支持动态添加/删除节点，自动迁移槽位和数据

• 高可用：每个主节点配置多个从节点，主节点故障时从节点自动晋升为主节点

七、核心性能优化点

1. 内存优先设计：所有数据操作在内存中完成，避免磁盘IO瓶颈
2. 高效数据结构：SDS、QuickList、Skiplist等定制化结构，平衡性能与内存占用
3. I/O多路复用：单线程处理数万并发连接，无阻塞I/O开销
4. 异步操作：持久化、复制等耗时操作通过fork子进程/线程执行，不阻塞主线程
5. 内存管理：jemalloc分配器+主动碎片整理，减少内存浪费和碎片问题

总结

Redis的高性能源于其单线程事件驱动模型、内存优先存储和高效数据结构的设计，而持久化、主从复制、哨兵和集群机制则保障了数据安全性和系统可用性。理解这些核心原理，有助于更好地使用Redis解决实际问题，避免常见陷阱（如内存溢出、数据丢失、性能瓶颈）。

需要我整理一份Redis面试高频原理题（含答案要点），方便你快速复习吗？

Redis缓存击穿解决方案

一、先明确：什么是缓存击穿

缓存击穿：
一个超高并发的热点Key（如爆款商品、热点活动），在Redis中突然过期/被删除，瞬间所有请求直接打到数据库，导致DB压力剧增甚至宕机。

简单区分：

• 击穿：单个热点key失效 → 打DB
• 穿透：查不存在的key → 缓存、DB都没有
• 雪崩：大量key同时过期 → 大面积打DB

二、核心解决方案（高频实用）

1. 互斥锁/分布式锁【强一致性首选】

原理
同一时间只允许一个线程去DB查询并重建缓存，其他线程等待重试，避免DB被打爆。

实现

• 简单方案：Redis SETNX + 超时（防锁死）
• 生产方案：Redisson 分布式锁（自动重试、锁续期、防死锁）

优点：数据强一致，无脏数据
缺点：高并发下有线程等待，性能略低

2. 热点Key永不过期【高并发首选】

原理

• 物理不过期：热点key不设置过期时间
• 逻辑过期：缓存存「数据+过期时间」，请求不判断过期，后台异步线程定时刷新

优点：无阻塞、极致高并发，彻底避免击穿
缺点：数据存在短暂不一致

3. 缓存预热 + 主动更新

原理

• 提前把热点数据加载进缓存（缓存预热）
• 数据更新时主动刷新缓存，不依赖自动过期
• 延长热点key过期时间，避开流量高峰

优点：从源头规避击穿
缺点：需要提前识别热点key

三、实战选型

1. 强一致要求 → Redisson分布式锁
2. 超高并发、可接受短暂不一致 → 逻辑永不过期
3. 常规业务 → 锁 + 延长过期时间 组合使用

需要我给你写一段Redisson 解决缓存击穿的可直接复制的代码吗？

Redis分布式锁原理及实战使用

你想深入理解Redis分布式锁的核心实现原理，同时掌握它在实际开发中的正确使用方式（包括可直接落地的代码），这是分布式系统中解决资源竞争的核心知识点，我会从原理到实战一步步讲清楚。

一、Redis分布式锁核心原理

1. 什么是Redis分布式锁

分布式锁是为了解决多进程/多服务跨机器竞争同一资源的问题（比如秒杀库存、订单号生成），而Redis分布式锁则是利用Redis的原子性命令，在分布式环境中实现互斥访问的锁机制。

2. 实现分布式锁的核心要求

一个合格的Redis分布式锁必须满足以下条件：

3. 分布式锁的实现演进（从基础到生产级）

（1）初级版：SETNX + EXPIRE（有坑）

• 加锁：SETNX lock_key client_id（只有key不存在时才设置成功，实现互斥）
• 续命：EXPIRE lock_key 30（设置过期时间，防死锁）
• ❌ 问题：SETNX和EXPIRE是两个命令，非原子操作！如果执行完SETNX后客户端崩溃，EXPIRE没执行，锁就会永久存在（死锁）。

（2）进阶版：SET原子命令（解决原子性问题）

Redis 2.6.12+支持SET命令的扩展参数，将加锁+过期时间合并为原子操作：

# 加锁：NX=只有key不存在时设置，PX=过期时间（毫秒），value用唯一标识（如UUID+线程ID）
SET lock_key unique_client_id NX PX 30000

• 解锁：必须用Lua脚本保证原子性（先判断锁是否是自己的，再删除）：

if redis.call('get', KEYS[1]) == ARGV[1] then
    return redis.call('del', KEYS[1])
else
    return 0
end

• ✅ 解决了原子性问题，但仍有缺陷：过期时间固定，如果业务执行时间超过过期时间，锁会提前释放，导致并发问题。

（3）生产级：Redisson分布式锁（自动续期+可重入）

Redisson是Redis官方推荐的Java客户端，封装了生产级的分布式锁实现，核心特性：

• 自动续期（WatchDog）：持有锁的客户端会启动一个后台线程，每隔10秒（默认）将锁的过期时间重置为30秒，避免业务未执行完锁就过期。
• 可重入：基于Hash结构记录线程的重入次数，支持同一线程多次加锁。
• 公平锁/非公平锁：默认非公平锁，也可配置公平锁（按请求顺序获取锁）。
• 自动释放：线程结束/客户端崩溃时，WatchDog停止续期，锁到期自动释放。

Redisson分布式锁的核心流程：

graph TD
    A[客户端请求加锁] --> B{SET lock_key unique_id NX PX 30000};
    B -- 成功 --> C[启动WatchDog后台线程续期];
    B -- 失败 --> D[等待/重试];
    C --> E[业务执行];
    E --> F[执行Lua脚本解锁（判断标识+删除）];
    F --> G[停止WatchDog];

二、实战使用（Java版）

1. 环境准备

首先引入Redisson依赖（以Maven为例）：

<!-- Redisson核心依赖 -->
<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.23.3</version> <!-- 建议使用最新稳定版 -->
</dependency>
<!-- Spring Boot整合依赖（可选，简化配置） -->
<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson-spring-boot-starter</artifactId>
    <version>3.23.3</version>
</dependency>

2. 方式1：基础手写实现（理解底层）

适合学习原理，生产环境建议用Redisson：

import redis.clients.jedis.Jedis;
import java.util.UUID;

public class RedisLockBasic {
    // Redis连接
    private static final Jedis JEDIS = new Jedis("127.0.0.1", 6379);
    // 锁过期时间（30秒）
    private static final long LOCK_EXPIRE = 30000L;
    // 解锁Lua脚本
    private static final String UNLOCK_LUA = 
        "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";

    /**
     * 加锁
     * @param lockKey 锁名称
     * @return 唯一标识（用于解锁），加锁失败返回null
     */
    public static String lock(String lockKey) {
        // 生成唯一标识（避免误删其他客户端的锁）
        String clientId = UUID.randomUUID().toString() + "-" + Thread.currentThread().getId();
        // 原子加锁：NX=不存在时设置，PX=毫秒过期
        String result = JEDIS.set(lockKey, clientId, "NX", "PX", LOCK_EXPIRE);
        return "OK".equals(result) ? clientId : null;
    }

    /**
     * 解锁
     * @param lockKey 锁名称
     * @param clientId 加锁时的唯一标识
     * @return 是否解锁成功
     */
    public static boolean unlock(String lockKey, String clientId) {
        // 执行Lua脚本，保证判断+删除的原子性
        Long result = (Long) JEDIS.eval(UNLOCK_LUA, 1, lockKey, clientId);
        return result != null && result == 1;
    }

    // 测试
    public static void main(String[] args) {
        String lockKey = "seckill:lock:1001"; // 秒杀商品ID
        String clientId = lock(lockKey);
        if (clientId != null) {
            try {
                // 执行业务逻辑（比如扣减库存）
                System.out.println("获取锁成功，执行秒杀业务...");
                Thread.sleep(5000); // 模拟业务耗时
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            } finally {
                // 解锁
                boolean unlockResult = unlock(lockKey, clientId);
                System.out.println("解锁结果：" + unlockResult);
            }
        } else {
            System.out.println("获取锁失败，请勿重复请求");
        }
        JEDIS.close();
    }
}

3. 方式2：Redisson生产级实现（推荐）

（1）Redisson配置

import org.redisson.Redisson;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class RedissonConfig {
    @Bean
    public RedissonClient redissonClient() {
        Config config = new Config();
        // 单机模式（集群/哨兵模式可参考官方文档配置）
        config.useSingleServer()
              .setAddress("redis://127.0.0.1:6379")
              .setPassword(null) // 有密码则设置
              .setDatabase(0);
        return Redisson.create(config);
    }
}

（2）分布式锁使用示例

import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import org.springframework.stereotype.Service;
import javax.annotation.Resource;
import java.util.concurrent.TimeUnit;

@Service
public class SeckillService {
    @Resource
    private RedissonClient redissonClient;

    /**
     * 秒杀业务（分布式锁实现）
     * @param productId 商品ID
     * @return 秒杀结果
     */
    public String seckill(Long productId) {
        // 定义锁名称（按业务维度区分）
        String lockKey = "seckill:lock:" + productId;
        // 获取锁对象
        RLock lock = redissonClient.getLock(lockKey);

        try {
            // 加锁：支持等待时间、自动释放时间（不设置则用WatchDog默认30秒）
            // 参数：waitTime（最多等5秒）、leaseTime（自动释放10秒）、时间单位
            boolean locked = lock.tryLock(5, 10, TimeUnit.SECONDS);
            if (!locked) {
                return "手速太慢，秒杀失败！";
            }

            // 核心业务逻辑：扣减库存、生成订单等
            System.out.println("用户" + Thread.currentThread().getId() + "秒杀成功，商品ID：" + productId);
            // 模拟业务耗时
            Thread.sleep(2000);

            return "秒杀成功！";
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            return "秒杀异常，请重试！";
        } finally {
            // 解锁：必须在finally中执行，避免锁泄漏
            if (lock.isHeldByCurrentThread()) {
                lock.unlock();
            }
        }
    }

    // 测试并发场景
    public static void main(String[] args) {
        // 模拟10个并发请求秒杀同一个商品
        SeckillService service = new SeckillService();
        // 实际项目中RedissonClient由Spring容器注入，此处简化
        service.redissonClient = Redisson.create(new Config().useSingleServer().setAddress("redis://127.0.0.1:6379"));

        for (int i = 0; i < 10; i++) {
            new Thread(() -> {
                String result = service.seckill(1001L);
                System.out.println(result);
            }).start();
        }
    }
}

4. 关键API说明

三、使用注意事项

1. 锁粒度要细：避免用全局锁（比如只用一个lock作为锁名），要按业务维度拆分（如seckill:lock:商品ID），减少锁竞争。
2. 避免长时间持有锁：业务逻辑要尽可能精简，锁持有时间越短越好。
3. 异常处理：解锁必须放在finally块中，且解锁前要判断isHeldByCurrentThread()，避免线程未获取到锁却执行解锁。
4. 集群场景：如果Redis是集群模式，建议用Redisson的RedLock（红锁），避免主从切换导致的锁丢失问题。

总结

1. 核心原理：Redis分布式锁的核心是利用SET key value NX PX原子命令实现互斥加锁，通过Lua脚本保证解锁的原子性；Redisson在此基础上增加了WatchDog自动续期、可重入等生产级特性。
2. 生产选型：手写实现仅用于学习原理，实际项目优先使用Redisson（封装完善、解决了大部分坑）。
3. 避坑关键：锁要加过期时间、解锁要校验唯一标识、锁粒度要细、解锁操作放在finally中。

Java JVM优化

你想要掌握Java JVM优化的核心思路和实操方法，这是提升Java应用性能、解决OOM/卡顿问题的关键。我会从基础原理→问题定位→优化策略→实战案例 一步步讲清楚，新手也能看懂、落地。

一、先理解JVM核心结构（优化的前提）

JVM优化的本质是对内存分配、垃圾回收（GC）、类加载等核心模块的调优，先明确核心内存区域：

核心：堆内存细分（GC优化的核心）

堆是JVM优化的重中之重，分为：

graph TD
    A[堆内存] --> B[新生代（Eden + S0 + S1）]
    A --> C[老年代]
    B --> D[Eden区（80%）]
    B --> E[Survivor0（10%）]
    B --> F[Survivor1（10%）]

• 新生代：存放新创建的对象，GC频率高（Minor GC），回收速度快；
• 老年代：存放存活时间长的对象，GC频率低（Major GC/Full GC），回收速度慢；
• 永久代（JDK7）/元空间（JDK8+）：元空间默认使用本地内存，不再占用堆空间。

二、JVM优化的核心目标

1. 减少Full GC次数：Full GC会暂停所有用户线程（STW，Stop The World），导致应用卡顿；
2. 降低GC停顿时间：Minor GC/Full GC的STW时间控制在可接受范围（比如毫秒级）；
3. 避免内存溢出：解决OOM（OutOfMemoryError）、StackOverflowError等问题；
4. 提升内存利用率：合理分配内存区域，避免内存浪费。

三、问题定位：先找到优化点（核心步骤）

优化前必须先定位问题，常用工具如下：

1. 基础命令（JDK自带，无需额外安装）

2. 可视化工具（分析堆快照/GC日志）

• MAT（Memory Analyzer Tool）：分析堆快照，定位内存泄漏、大对象；
• JProfiler/YourKit：商业工具，可视化监控GC、线程、内存（新手友好）；
• GCViewer：分析GC日志，查看GC频率、停顿时间。

3. 核心分析指标

• GC频率：Minor GC每秒>1次 → 新生代过小；Full GC每分钟>1次 → 老年代/GC算法有问题；
• GC停顿时间：Minor GC>50ms、Full GC>1s → 需要优化；
• 内存使用率：老年代使用率长期>80% → 容易触发Full GC；
• OOM类型：

• java.lang.OutOfMemoryError: Java heap space → 堆内存不足；
• java.lang.OutOfMemoryError: Metaspace → 元空间不足；
• java.lang.StackOverflowError → 栈深度过大（递归/方法调用过深）。

四、核心优化策略（从易到难）

1. 内存参数调优（最基础、最有效）

JVM内存参数通过启动参数（-X开头）配置，核心参数如下：

（1）堆内存核心参数

（2）元空间/栈参数

（3）直接内存参数

2. GC算法调优（根据业务场景选择）

JDK8默认使用Parallel GC（并行GC），JDK9+默认使用G1 GC，不同GC算法适配不同场景：

G1 GC核心优化参数（推荐重点掌握）

# 启用G1 GC
-XX:+UseG1GC
# 目标GC停顿时间（默认200ms，根据业务调整）
-XX:MaxGCPauseMillis=100
# 新生代占比（默认5%，可设10%-70%）
-XX:G1NewSizePercent=20
-XX:G1MaxNewSizePercent=50
# 老年代占比达到该值触发混合回收（默认45%）
-XX:InitiatingHeapOccupancyPercent=40

3. 代码层面优化（从源头减少GC压力）

JVM参数调优是“治标”，代码优化是“治本”：

1. 减少大对象创建：

• 避免频繁创建大字符串/大数组，可复用对象（如StringBuilder替代String拼接）；
• 大对象（>1M）直接进入老年代，会增加老年代GC压力，尽量拆分。

1. 避免内存泄漏：

• 关闭资源（IO、数据库连接、Redis连接），使用try-with-resources；
• 避免静态集合（如static List）无限存储对象，及时清理无用引用；
• 慎用ThreadLocal，用完后调用remove()（避免线程池场景内存泄漏）。

1. 减少对象存活时间：

• 局部变量优先（方法执行完立即回收），避免全局变量；
• 批量处理数据时，分批次提交（避免一次性加载大量数据到内存）。

4. 类加载优化（减少元空间占用）

• 移除无用依赖（避免加载多余类）；
• 使用轻量级框架（减少反射生成的类）；
• 关闭无用的JVM内置功能（如-XX:-UseBiasedLocking关闭偏向锁，减少类元数据）。

四、实战案例（常见场景优化）

案例1：电商系统OOM（堆内存不足）

问题现象

• 高峰期报Java heap space OOM；
• jstat查看老年代使用率长期>90%，Full GC每分钟触发5+次。

优化步骤

1. 调整堆内存：-Xms8g -Xmx8g -Xmn4g（原配置-Xms2g -Xmx4g，内存不足）；
2. 切换GC算法：-XX:+UseG1GC -XX:MaxGCPauseMillis=100（原Parallel GC，STW时间长）；
3. 代码优化：批量查询订单时，分页加载（每页100条），避免一次性加载10万+订单到内存；
4. 结果：Full GC从每分钟5次降至每小时1次，OOM问题解决，接口响应时间从500ms降至100ms。

案例2：接口卡顿（Full GC停顿时间长）

问题现象

• 接口偶尔卡顿（1-2秒无响应）；
• GC日志显示Full GC停顿时间>1.5秒。

优化步骤

1. 调整G1 GC参数：-XX:MaxGCPauseMillis=50 -XX:InitiatingHeapOccupancyPercent=30（提前触发混合回收，减少单次GC工作量）；
2. 减少大对象：将2M的JSON字符串拼接改为StringBuilder，避免频繁创建大对象；
3. 开启字符串常量池优化：-XX:+UseStringDeduplication（G1 GC特有，去重重复字符串，节省内存）；
4. 结果：Full GC停顿时间降至200ms以内，接口卡顿消失。

五、优化注意事项

1. 先监控后优化：不要盲目调参，必须先通过工具定位问题（比如内存泄漏不能只靠加堆内存）；
2. 小步调优：每次只改1-2个参数，对比优化前后的GC指标，避免一次性改多个参数；
3. 适配业务场景：

• 吞吐量优先（批处理）→ Parallel GC；
• 低延迟优先（微服务）→ G1 GC/ZGC；

1. 避免过度优化：GC停顿时间<100ms、Full GC每小时<1次，即可满足大部分业务需求，无需追求“零GC”；
2. 压测验证：优化后必须通过压测（如JMeter）验证，确保高并发下稳定。

总结

1. 核心思路：JVM优化的核心是“先定位问题→再针对性调优”，优先优化代码（减少GC压力），再调JVM参数（适配内存/GC）；
2. 关键参数：堆内存（-Xms/-Xmx/-Xmn）、GC算法（G1 GC为主）、停顿时间（MaxGCPauseMillis）是基础且有效的优化点；
3. 避坑要点：不要盲目增大堆内存（过大堆会导致Full GC停顿更长），内存泄漏必须通过代码优化解决，而非加内存。

JAVA垃圾回收器有哪些

你想全面了解Java中不同的垃圾回收器（GC），包括它们的核心原理、特点和适用场景，这是JVM调优的核心基础——选择合适的GC比盲目调参更重要。我会按「经典GC→现代GC」的演进顺序讲解，帮你快速匹配业务场景。

一、Java垃圾回收器核心分类

Java GC的演进核心是：从「单线程STW」→「多线程并行」→「并发回收（低停顿）」→「超低停顿（毫秒级）」，不同GC适配不同的内存规模和性能需求。先看整体分类：

二、各垃圾回收器详细解析

1. 串行回收器（Serial GC）

核心原理

• 新生代：复制算法，单线程回收，全程STW（Stop The World，暂停所有用户线程）；
• 老年代：标记-整理算法，同样单线程、全程STW。

核心参数

-XX:+UseSerialGC  # 启用串行GC（新生代+老年代均串行）

特点

• ✅ 优点：实现简单、内存占用极低（无多线程开销）、GC逻辑无竞争；
• ❌ 缺点：单线程回收，STW时间长（堆内存>1G时停顿明显）；

适用场景

• 客户端程序（如桌面应用、小工具）；
• 单核CPU、小内存（<1G）的服务器；
• 嵌入式系统（资源受限场景）。

2. 并行回收器（Parallel GC/吞吐量优先GC）

核心原理

• 新生代：多线程复制算法，STW但多线程加速回收；
• 老年代：多线程标记-整理算法，JDK8默认启用UseParallelOldGC（老年代并行）。

核心参数

-XX:+UseParallelGC       # 新生代并行回收
-XX:+UseParallelOldGC    # 老年代并行回收（JDK8默认开启）
-XX:ParallelGCThreads=N  # 设置GC线程数（建议等于CPU核心数）
-XX:MaxGCPauseMillis=N   # 目标停顿时间（GC会尽量满足，但可能牺牲吞吐量）

特点

• ✅ 优点：多线程回收，吞吐量极高（CPU利用率高），STW比Serial短；
• ❌ 缺点：仍有明显STW（堆越大停顿越长），无法满足低延迟需求；

适用场景

• 后台批处理任务（如数据ETL、报表生成）；
• 大数据计算（如Hadoop MapReduce）；
• 吞吐量优先、对延迟不敏感的场景。

3. CMS回收器（Concurrent Mark Sweep）

核心原理

专门针对老年代的并发低停顿回收器，采用「标记-清除算法」，核心分4步：

1. 初始标记：STW，标记GC Roots直接关联的对象（耗时极短）；
2. 并发标记：和用户线程并行，遍历标记所有可达对象（无STW）；
3. 重新标记：STW，修正并发标记期间的对象状态（耗时短）；
4. 并发清除：和用户线程并行，清除无用对象（无STW）。

核心参数

-XX:+UseConcMarkSweepGC  # 启用CMS（新生代默认用ParNew，并行回收）
-XX:CMSInitiatingOccupancyFraction=N  # 老年代使用率达到N%触发CMS（默认68）
-XX:+CMSFullGCsBeforeCompaction=N     # 每N次Full GC后进行一次内存整理（解决碎片）

特点

• ✅ 优点：低停顿（大部分阶段和用户线程并行），适合低延迟场景；
• ❌ 缺点：

• 内存碎片（标记-清除算法导致）；
• CPU占用高（并发回收抢占CPU资源）；
• 浮动垃圾（并发清除时产生的新垃圾，需下次GC处理）；
• JDK9已废弃，被G1替代。

适用场景

• JDK8及之前的低延迟场景（如电商交易系统）；
• 堆内存2-4G、对延迟敏感但吞吐量要求不极致的场景。

4. G1 GC（Garbage-First）

核心原理

JDK9+默认GC，兼顾吞吐量和低延迟，核心设计是「分区回收」：

• 将堆分成多个大小相等的Region（区域），新生代、老年代不再物理隔离，而是分散在不同Region；
• 优先回收垃圾最多的Region（Garbage-First），减少STW时间；
• 新生代用复制算法，老年代用标记-整理算法（无内存碎片）。

核心参数

-XX:+UseG1GC              # 启用G1 GC
-XX:MaxGCPauseMillis=200  # 目标停顿时间（默认200ms，GC会尽量满足）
-XX:G1NewSizePercent=20   # 新生代最小占比（默认5%）
-XX:G1MaxNewSizePercent=50 # 新生代最大占比（默认60%）

特点

• ✅ 优点：

• 可设置目标停顿时间，精准控制延迟；
• 分区回收，STW时间短且可控；
• 无内存碎片，支持中大型堆（4G-32G）；

• ❌ 缺点：CPU占用略高于Parallel GC，超大堆（>32G）性能下降。

适用场景

• 互联网微服务、分布式系统（如Spring Cloud应用）；
• 中大型堆（4G+）、兼顾吞吐量和低延迟的场景；
• 替代CMS的主流选择（JDK8+也推荐使用）。

5. ZGC（Z Garbage Collector）

核心原理

JDK11引入（实验性）、JDK17正式发布的超低停顿GC，核心技术：

• 「着色指针」：将对象的GC状态存储在指针中，无需扫描堆；
• 「读屏障」：并发回收时拦截对象读取，避免STW；
• 全程并发（初始标记/重新标记的STW时间<1ms），支持TB级堆内存。

核心参数

-XX:+UseZGC  # 启用ZGC（仅支持Linux/x64，JDK17+支持Windows/macOS）
-XX:ZHeapSize=32g  # 设置堆大小（支持超大堆）

特点

• ✅ 优点：

• STW时间极短（<10ms），几乎无感知；
• 支持超大堆（16G-TB级）；
• 无内存碎片；

• ❌ 缺点：吞吐量略低于G1（CPU开销更高）；

适用场景

• 超大堆场景（如金融核心系统、电商秒杀系统）；
• 高并发、超低延迟要求（STW<10ms）的场景；
• JDK17+生产环境（JDK11为实验性）。

6. Shenandoah GC

核心原理

和ZGC类似的超低停顿GC，由RedHat开发，核心差异是「无着色指针」，通过读屏障实现并发回收。

核心参数

-XX:+UseShenandoahGC  # 启用Shenandoah（OpenJDK12+，JDK17正式）

特点

• ✅ 优点：

• STW时间<10ms，支持超大堆；
• 跨平台（Linux/Windows/macOS）；

• ❌ 缺点：吞吐量略低于G1；

适用场景

• 低延迟、跨平台的超大堆场景；
• 无法使用ZGC（如Windows环境）的超低延迟场景。

三、GC选择实战指南

总结

1. 核心权衡：GC的「吞吐量」和「延迟」是反比关系，没有最优GC，只有适配业务的GC；
2. 版本适配：JDK8默认Parallel GC，JDK9+默认G1 GC，JDK17+推荐ZGC（超低延迟）；
3. 选型原则：小内存选串行、吞吐量选并行、中堆低延迟选G1、超大堆超低延迟选ZGC/Shenandoah。