往List持续写入数据遇OutOfMemoryError时，如何截断旧数据释放内存？

这个场景我之前做物联网数据采集时碰到过，先给你理清楚核心问题，再给你几个落地可行的方案：

首先你踩了一个subList()的坑——它返回的是原列表的视图，不是独立的新列表，原列表里的所有元素依然被强引用着，根本不会释放内存，OOM的问题依然存在。而且更糟的是，当OutOfMemoryError抛出时，JVM的内存已经濒临耗尽，这时候任何需要分配内存的操作（比如创建新列表）都可能再次触发OOM，导致你的catch块都执行不下去。

方案1：提前监控，主动裁剪（推荐） #

不要等到OOM才处理，这是最不可靠的时机。提前给列表设置一个合理的最大阈值，当接近阈值时主动裁剪，从根源避免内存耗尽：

// 根据你的内存配置和业务场景，定义一个合理的最大队列容量
private static final int MAX_QUEUE_SIZE = 10000;

public static void pushSensorData(String sensorData) { 
    // 先检查队列大小，超过阈值就主动裁剪前半部分
    if (sensorQueue.size() >= MAX_QUEUE_SIZE) {
        int halfSize = sensorQueue.size() / 2;
        // 用subList的clear方法直接修改原列表，释放内存（比循环删除效率高）
        sensorQueue.subList(0, halfSize).clear();
        System.out.println("Queue trimmed to free up space");
    }
    
    try { 
        sensorQueue.add(parsePacket(sensorData)); 
    } catch (Exception e) { 
        // 这里只处理数据包解析的异常，OOM风险已经提前规避
        System.err.println("Failed to parse sensor data: " + e.getMessage());
    } 
    System.out.println(sensorQueue.size()); 
}

这个方案的优势是：在内存充足的时候操作，不会遇到OOM时的各种意外，而且subList(0, half).clear()是ArrayList内部优化过的删除方式（直接移动数组元素，把多余位置置null，方便GC快速回收）。

方案2：OOM时的应急兜底处理（不推荐，但可作为最后防线） #

如果一定要处理OOM的情况，那你需要在catch块里做最轻量化的操作，绝对避免任何额外内存分配：

public static void pushSensorData(String sensorData) { 
    try { 
        sensorQueue.add(parsePacket(sensorData)); 
    } catch (OutOfMemoryError e) { 
        System.out.println("Backlog full, trimming queue..."); 
        // 极端内存不足时，先确保队列不为空再操作
        if (!sensorQueue.isEmpty()) {
            int halfSize = sensorQueue.size() / 2;
            // 直接修改原列表释放内存，不要创建新列表
            sensorQueue.subList(0, halfSize).clear();
            // 尝试再次添加当前数据
            try {
                sensorQueue.add(parsePacket(sensorData));
            } catch (OutOfMemoryError ex) {
                // 极端情况：裁剪后还是没内存，只能丢弃当前数据
                System.err.println("Failed to add data even after trimming: " + ex.getMessage());
            }
        }
    } 
    System.out.println(sensorQueue.size()); 
}

注意：这里绝对不能用sensorQueue = sensorQueue.subList(...)赋值——因为subList是视图，原列表的引用如果被其他地方持有，依然不会释放内存；而且创建新列表（比如new ArrayList<>(subList...)）会在OOM时分配新内存，大概率再次触发崩溃。

方案3：换用环形队列（最优解） #

如果你的业务允许丢弃最早的元素，那直接用固定大小的环形队列是最好的选择，从根源上杜绝OOM：

// 固定容量的环形队列，满了自动覆盖最早的元素
private static final int QUEUE_CAPACITY = 10000;
private static final Deque<SensorPacket> sensorQueue = new ArrayDeque<>(QUEUE_CAPACITY) {
    @Override
    public boolean add(SensorPacket packet) {
        // 队列满了就先移除最早的元素
        if (size() >= QUEUE_CAPACITY) {
            removeFirst();
        }
        return super.add(packet);
    }
};

public static void pushSensorData(String sensorData) { 
    try { 
        sensorQueue.add(parsePacket(sensorData)); 
    } catch (Exception e) { 
        System.err.println("Failed to parse sensor data: " + e.getMessage());
    } 
    System.out.println(sensorQueue.size()); 
}

这个方案完全不需要处理OOM，队列大小永远不会超过设定的容量，内存占用始终可控，而且添加/删除元素的效率都很高。

关键提醒 #

• 永远不要依赖OutOfMemoryError来做业务逻辑处理，因为OOM发生时JVM状态极不稳定，可能连日志都打不出来，甚至catch块都无法执行。
• subList()的坑一定要记牢：它是原列表的视图，修改subList会影响原列表；如果原列表被直接修改（比如add/remove元素），再操作subList会抛出ConcurrentModificationException。

内容的提问来源于stack exchange，提问作者UmBottesWillen