4. 内存管理与优化：内存分配与回收、对象池技术、减少内存碎片、JVM/GC调优基础

内存管理，说白了就是程序跟操作系统“借”和“还”内存的过程。很多性能问题，追根溯源都是内存没管好。我个人习惯把内存优化看作系统调优的“第一颗纽扣”——这颗扣错了，后面全白搭。

4.1 内存分配与回收：别让系统“手忙脚乱”

内存分配，就是程序向系统申请一块空间来放数据。回收呢，就是不用了还回去。听起来简单，但这里面的门道不少。

我在项目中遇到过一个问题：一个高并发的网关服务，每秒钟要处理几万个请求。每个请求都new一个对象，用完就丢。结果呢？GC频繁触发，CPU飙升，吞吐量直接腰斩。

为什么会这样？因为频繁的内存分配和回收，会让系统疲于奔命。你想想看，每次分配都要找一块连续的空闲内存，每次回收都要标记、清理、整理。这就像图书馆里，读者不停地借书还书，管理员就得不停地整理书架。

核心原则：减少内存分配次数，降低GC压力。

具体怎么做？我总结了几个实用技巧：

避免在热点路径上创建对象——比如循环体内不要new对象
使用基本类型替代包装类型——int比Integer省内存，还省去了装箱拆箱的开销
合理设置初始容量——ArrayList、HashMap这些容器，如果能预估大小，就指定初始容量，避免扩容带来的额外分配

// 不好的写法：循环内频繁创建对象
for (int i = 0; i < 100000; i++) {
    String s = new String("hello");  // 每次循环都分配内存
}

// 好的写法：复用对象
String s = "hello";
for (int i = 0; i < 100000; i++) {
    // 直接使用s，不创建新对象
}

4.2 对象池技术：把“借还”变成“复用”

对象池，说白了就是提前创建一批对象，放在池子里。用的时候从池子里拿，用完再放回去。这样就不用频繁地创建和销毁了。

我记得有一次优化一个数据库连接池，发现连接池大小设置不合理，导致大量连接创建和销毁。调整之后，响应时间从200ms降到了50ms。嗯，这里要注意，对象池不是万能的，它适合那些创建成本高、复用频率高的对象。

场景	适合对象池吗？	原因
数据库连接	✅ 非常适合	创建连接开销大，复用率高
线程	✅ 非常适合	线程创建销毁成本高
简单POJO对象	❌ 不太适合	创建成本低，池化反而增加复杂度
大对象（如byte[]）	⚠️ 视情况而定	能减少GC压力，但池子本身也占内存

小技巧：实现对象池时，记得设置最大容量和超时时间。我曾经见过一个没有上限的对象池，结果内存被撑爆了……

// 一个简单的对象池示例
public class SimpleObjectPool<T> {
    private final List<T> pool = new ArrayList<>();
    private final Supplier<T> factory;
    private final int maxSize;

    public SimpleObjectPool(Supplier<T> factory, int maxSize) {
        this.factory = factory;
        this.maxSize = maxSize;
    }

    public T borrow() {
        synchronized (pool) {
            if (pool.isEmpty()) {
                return factory.get();  // 池子空了，创建新的
            }
            return pool.remove(pool.size() - 1);  // 从池子里拿
        }
    }

    public void return_(T obj) {
        synchronized (pool) {
            if (pool.size() < maxSize) {
                pool.add(obj);  // 放回池子
            }
            // 如果池子满了，就丢弃，让GC去回收
        }
    }
}

4.3 减少内存碎片：让内存“整整齐齐”

内存碎片，就是内存被分割成很多小块，虽然总空闲空间够用，但找不到一块连续的大空间来分配。这就像你有一堆零钱，但想买一个100块的东西，凑不齐整张的。

我建议从两个层面来考虑：

系统层面：使用内存池、伙伴系统等算法来管理内存。这些是操作系统和运行时的事情，我们一般改不了。
应用层面：尽量分配大小相近的对象。比如，如果你需要很多byte数组，尽量都用同样的大小。这样内存分配器更容易找到合适的位置。

注意：在JVM中，频繁创建不同大小的对象会导致老年代碎片化，最终引发Full GC。我曾经在一个日志处理系统里，因为对象大小差异太大，导致老年代碎片严重，Full GC频繁触发，每次停顿好几秒。

怎么解决？一个实用的方法是使用预分配缓冲区。比如，处理网络消息时，提前分配一个固定大小的byte[]，每次都用这个缓冲区来读写数据。

// 预分配缓冲区，避免频繁创建不同大小的byte[]
public class MessageProcessor {
    private static final int BUFFER_SIZE = 4096;
    private final byte[] buffer = new byte[BUFFER_SIZE];

    public void process(InputStream in) throws IOException {
        int bytesRead = in.read(buffer);
        // 处理数据...
    }
}

4.4 JVM/GC调优基础：让垃圾回收“恰到好处”

JVM的垃圾回收，说白了就是自动帮我们回收不再使用的对象。但自动不代表完美，调优是必须的。

我刚开始学GC调优时，总觉得参数越多越好。后来发现，很多时候默认参数就够用了。调优的关键是理解你的应用：

是CPU密集型还是IO密集型？
对象存活时间短还是长？
对停顿时间敏感吗？

根据这些特点，选择合适的GC算法：

GC算法	适用场景	特点
Serial GC	单核CPU、小内存应用	简单高效，但停顿时间长
Parallel GC	多核CPU、高吞吐量需求	并行回收，吞吐量高
CMS GC	低延迟需求	并发回收，停顿时间短
G1 GC	大内存、多核CPU	可预测停顿时间，JDK 9+默认

调优口诀：先让程序跑起来，再根据监控数据调参数。不要一开始就追求“最优配置”。

我建议的调优步骤：

设置合理的堆大小——-Xms和-Xmx设置成一样，避免运行时扩容
选择合适的GC算法——根据应用特点来选
监控GC日志——-XX:+PrintGCDetails -XX:+PrintGCDateStamps
分析GC频率和停顿时间——如果Young GC频繁，考虑增大年轻代；如果Full GC频繁，检查是否有内存泄漏
逐步调整参数——一次只改一个参数，观察效果

# 一个典型的JVM参数配置
-Xms4g -Xmx4g 
-XX:+UseG1GC 
-XX:MaxGCPauseMillis=200 
-XX:+PrintGCDetails 
-XX:+PrintGCDateStamps 
-Xloggc:/path/to/gc.log

避坑指南：我曾经把-Xms设得很小，-Xmx设得很大，以为这样能“弹性伸缩”。结果呢？应用启动后频繁触发GC来扩容，性能反而更差了。记住，-Xms和-Xmx最好设成一样。

最后说一句，内存优化没有银弹。每个应用都有自己的特点，关键是要理解原理，然后根据实际情况来调整。嗯，多动手、多观察、多总结，慢慢就有感觉了。

📚 课程目录

4. 内存管理与优化：内存分配与回收、对象池技术、减少内存碎片、JVM/GC调优基础

4.1 内存分配与回收：别让系统“手忙脚乱”

4.2 对象池技术：把“借还”变成“复用”

4.3 减少内存碎片：让内存“整整齐齐”

4.4 JVM/GC调优基础：让垃圾回收“恰到好处”