深入解析数组下标越界，ArrayIndexOutOfBoundsException问题debug日志

原创

鼓掌MVP

发布于 2025-09-27 10:34:58

4750

引言

在Java开发中，ArrayIndexOutOfBoundsException 是一个常见但容易被忽视的运行时异常。这个异常看似简单，但在复杂系统中往往隐藏着深层次的设计问题。本文将通过一个真实案例，深入分析数组下标越界问题的本质、排查过程和解决方案，并探讨如何从根本上避免这类问题。

技术环境

Java版本: JDK 11
框架: Spring Boot 2.7.x
构建工具: Maven 3.8.x
测试工具: JUnit 5, Mockito
日志框架: Logback + SLF4J
IDE: IntelliJ IDEA 2022.x

我们记录一个在实际开发中遇到的数组下标越界异常。这个异常通常发生在访问数组时，索引值为负数或大于等于数组长度。在开发一个数据导出功能时，需要将数据库查询到的数据按一定规则分组，然后每组数据生成一个Excel文件。在分组过程中，由于对数据量估计不足，导致在分组时计算数组索引出现越界。

在测试环境中，当数据量较大时（例如超过10000条记录），程序偶尔会抛出ArrayIndexOutOfBoundsException异常，导致导出任务失败。

排查步骤：

查看异常堆栈信息，确定异常发生的具体代码行。
分析该行代码的数组访问逻辑，检查索引的计算方式。
检查数据分组的算法，确认分组规则是否正确。
模拟大量数据，重现问题。

代码示例（简化版，仅用于说明问题）：

原代码：

public class DataExporter {
    public void exportData(List<DataRecord> records) {
        // 假设每组最多1000条记录
        int groupSize = 1000;
        int groupCount = (records.size() + groupSize - 1) / groupSize;
        String[] fileNames = new String[groupCount];

        for (int i = 0; i < groupCount; i++) {
            int start = i * groupSize;
            int end = start + groupSize;
            // 当最后一组时，end可能超过records.size()
            if (end > records.size()) {
                end = records.size();
            }
            List<DataRecord> subList = records.subList(start, end);
            // 生成Excel文件，返回文件名
            fileNames[i] = generateExcelFile(subList);
        }
    }
}

问题：在计算groupCount时，我们使用了向上取整的方法，这个是正确的。但是在循环中，我们使用subList方法，其中start和end的计算在大多数情况下是正常的，但是当records.size()正好是groupSize的整数倍时，最后一组的end值等于records.size()，这是合法的，因为subList的end索引是exclusive的，所以不会越界。

但是，为什么会出现数组越界呢？实际上，问题并不是出在这段代码上，而是出在另一个类似的分组算法中，如下：

有问题的代码：

public class ProblematicExporter {
    public void exportData(List<DataRecord> records) {
        // 另一种分组方式：将记录分成10组
        int groupCount = 10;
        int groupSize = records.size() / groupCount;
        String[] fileNames = new String[groupCount];

        for (int i = 0; i < groupCount; i++) {
            int start = i * groupSize;
            int end = (i == groupCount - 1) ? records.size() : start + groupSize;
            List<DataRecord> subList = records.subList(start, end);
            fileNames[i] = generateExcelFile(subList);
        }
    }
}

这个算法的问题在于，当记录数不能被groupCount整除时，最后一组会包含剩余的所有记录，但是前面的分组每组都是groupSize条记录。

然而，在计算groupSize时，我们使用了整数除法，这会导致groupSize可能小于实际需要的尺寸。例如，如果records.size()=1005，groupCount=10，那么groupSize=100，这样最后一组从900开始，到1005结束，但是总共只有10组，数组fileNames的长度为10，索引从0到9，不会越界。

但是，如果records.size()小于groupCount，比如records.size()=5，groupCount=10，那么groupSize=0，然后循环10次，第一次start=0, end=0，subList(0,0)没问题，但是第二次start=0, end=0，再次调用subList(0,0)也没问题，但是第三次直到第十次，都是这样。但是，注意，我们数组fileNames的长度是10，所以循环10次不会越界。所以这个算法也不会导致数组越界。

那么，到底哪里会导致数组越界呢？我们再来看一个更隐蔽的例子：

public class AnotherProblem {
    public void process(String[] data, int numParts) {
        int partSize = data.length / numParts;
        String[] results = new String[numParts];

        for (int i = 0; i < numParts; i++) {
            int start = i * partSize;
            int end = (i == numParts - 1) ? data.length : start + partSize;
            // 处理每一部分
            results[i] = processPart(data, start, end);
        }
    }

    private String processPart(String[] data, int start, int end) {
        // 处理从start到end-1的元素
        StringBuilder sb = new StringBuilder();
        for (int j = start; j < end; j++) {
            sb.append(data[j]);
        }
        return sb.toString();
    }
}

这个例子中，如果data.length=10, numParts=3，那么partSize=3，循环3次： i=0: start=0, end=3 -> 索引0,1,2 i=1: start=3, end=6 -> 索引3,4,5 i=2: start=6, end=10 -> 索引6,7,8,9

这看起来正常。但是，如果data.length=0, numParts=3，那么partSize=0，循环3次： i=0: start=0, end=0 -> 不会进入内层循环 i=1: start=0, end=0 -> 同样不会进入内层循环 i=2: start=0, end=0 -> 同样不会进入内层循环

但是，如果data.length=2, numParts=3，那么partSize=0，循环3次： i=0: start=0, end=0 -> 处理空数组 i=1: start=0, end=0 -> 空数组 i=2: start=0, end=2 -> 索引0,1

这里，我们注意到，当data.length小于numParts时，partSize为0，导致前numParts-1组都是空，最后一组包含所有数据。但是，数组results的长度为numParts=3，循环3次，索引0,1,2，没有越界。

那么，到底什么情况会越界？我们再看一个例子：

public class YetAnotherProblem {
    public static void main(String[] args) {
        int[] array = new int[10];
        for (int i = 0; i <= 10; i++) {
            array[i] = i; // 当i=10时，越界
        }
    }
}

这是最经典的越界情况：循环条件写成了i<=array.length，而数组索引从0到9，索引10越界。

但是，在实际开发中，我们可能不会写出这样明显的错误。更常见的情况是在复杂的循环条件中计算索引。

再举个案例：订单处理系统中的数组越界问题

1. Bug现象描述

在一订单处理系统中，当处理批量订单导入功能时，偶尔会出现ArrayIndexOutOfBoundsException异常，导致整个批量导入流程中断。异常信息如下：

2. 问题影响范围

用户上传的订单CSV文件在解析时失败
批量处理任务中断，需要人工干预
数据一致性受到影响
系统稳定性下降

3. 初步排查

3.1 复现问题

首先尝试复现问题：

准备包含100条订单记录的CSV文件
上传文件并触发批量处理
观察系统行为

发现：

问题不是100%复现，概率约5%
当问题发生时，总是在处理第10条订单时出现

3.2 代码审查

举个例子，当我们查看OrderBatchProcessor.parseOrderItems()方法的时候，可看到代码如下：

public List<OrderItem> parseOrderItems(String[] itemLines) {
    List<OrderItem> items = new ArrayList<>();
    
    // 假设每个订单项占一行，格式为"商品ID,数量,单价"
    for (int i = 0; i < itemLines.length; i++) {
        String[] parts = itemLines[i].split(",");
        if (parts.length != 3) {
            throw new IllegalArgumentException("Invalid item format");
        }
        
        OrderItem item = new OrderItem();
        item.setProductId(parts[0]);
        item.setQuantity(Integer.parseInt(parts[1]));
        item.setPrice(new BigDecimal(parts[2]));
        items.add(item);
    }
    
    return items;
}

初步看代码逻辑没有问题，但为什么会出现数组越界？

3.3 日志分析

检查系统日志，发现异常发生时总是伴随着以下日志：

INFO  OrderBatchProcessor - Processing batch with 100 orders
INFO  OrderBatchProcessor - Processing order #10
ERROR OrderBatchProcessor - Failed to parse item line: null
java.lang.ArrayIndexOutOfBoundsException: Index 10 out of bounds for length 10

出现的问题是：

正在处理第10个订单时出错
错误信息显示尝试解析的行是null

4. 深入排查

4.1 数据流分析：CSV文件 → 文件读取 → 行分割 → 订单解析 → 订单项解析

发现：

文件读取后，行数据被存储在List<String>中
订单解析时，将List转换为数组String[]
订单项解析时使用该数组

4.2 多线程问题

考虑到批量处理可能使用多线程，检查线程安全代码处理如下：

public class OrderBatchProcessor {
    private String[] allLines; // 共享变量
    
    public void processBatch(List<String> lines) {
        this.allLines = lines.toArray(new String[0]); // 转换为数组
        // 多线程处理...
    }
    
    public void parseOrder(int orderIndex) {
        String[] orderItems = ... // 从allLines中提取
        parseOrderItems(orderItems);
    }
}

结论

数组下标越界问题看似简单，但在复杂系统中往往隐藏着设计缺陷。通过本文的深入分析，我们不仅解决了眼前的异常问题，更从架构层面进行了改进。主要经验包括：

始终对外部输入保持怀疑态度
在数组操作周围建立防御性边界
考虑使用更高层次的抽象替代裸数组
在多线程环境下特别小心共享状态
通过全面的测试覆盖各种边界情况

最终，解决数组越界问题的最佳方法不是简单地添加边界检查，而是通过良好的软件设计和工程实践，从根本上减少这类问题的发生概率。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

腾讯技术创作特训营S15#debug日志

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

腾讯技术创作特训营S15#debug日志

登录后参与评论

0 条评论

热度