本文讲解如何安全遍历两个大小不一的日期关联列表（如 fff 表与 holdings 表），避免 IndexOutOfBoundsException，并确保 if 条件正确触发，重点解决因边界判断缺失、循环逻辑错位导致的逻辑失效问题。
本文讲解如何安全遍历两个大小不一的日期关联列表（如 fff 表与 holdings 表），避免 `indexoutofboundsexception`，并确保 `if` 条件正确触发，重点解决因边界判断缺失、循环逻辑错位导致的逻辑失效问题。
在 Java 开发中，当需基于日期关联多个不等长数据源（如数据库查询结果映射为 List）时，常见错误包括：索引越界（IndexOutOfBoundsException） 和 if 条件始终不成立（逻辑跳过）。这些问题往往源于未对集合边界进行严谨校验、嵌套循环控制不当，或误用 break/continue 打断关键流程。
以下以实际场景为例：
- fff 表提供待处理的日期区间（filteredStartDate / filteredEndDate）；
- holdings 表（即 listOfNonConsolidatedHoldings）仅包含部分日期对应的持有人信息，且长度远小于 fff；
- 目标是：对每个 fff 日期，查找 holdings 中匹配的 start_date，若找到且与前一行持有人相同，则执行 A 逻辑；否则执行 B 逻辑。
❌ 原代码核心问题分析
-
if 条件不进入
if (filteredStartDate.get(i).equals(listOfNonConsolidatedHoldings.get(j).getId().getStartDate()))
- j 循环从 0 开始，但 listOfNonConsolidatedHoldings 可能为空或不含匹配项，而 break 写在 if 外层，导致 j 永远只遍历第 0 个元素后就跳出 —— 即使第 0 项不匹配，也不会继续查找。
-
索引越界（j - 1）
立即学习“Java免费学习笔记（深入）”；
listOfNonConsolidatedHoldings.get(j - 1) // 当 j == 0 时，j-1 = -1 → 越界！
- 未校验 j > 0 就访问 j-1，且该判断写在 if 内部，但 j 本身可能为 0。
-
逻辑耦合混乱
- restrictedHoldings.add(...) 在多处重复调用，且依赖 i-1 索引，但 i 与 j 并非一一对应（两表长度不等），导致 restrictedHoldings.get(i-1) 在 i==0 时非法，或在 restrictedHoldings.size() < i 时越界。
✅ 正确实践：解耦遍历 + 安全索引 + 显式状态管理
推荐采用「外层驱动 + 内层查找」模式，避免嵌套索引强依赖：
// 假设已将 holdings 映射为 Map<LocalDate, String> 提升查找效率（推荐）
Map<LocalDate, String> holdingsMap = new HashMap<>();
for (NonConsolidatedHolding holding : listOfNonConsolidatedHoldings) {
LocalDate date = holding.getId().getStartDate();
holdingsMap.put(date, holding.getHolderName());
}
// 主循环：遍历 fff 的每个日期
for (int i = 0; i < filteredStartDate.size(); i++) {
LocalDate currentStart = filteredStartDate.get(i);
LocalDate currentEnd = filteredEndDate.get(i);
// 步骤1：安全查找当前日期对应的 holderName
String currentHolder = holdingsMap.get(currentStart);
// 步骤2：判断是否可比较“连续性”（需至少有前一个有效 holder）
boolean isConsecutiveSame = false;
if (i > 0 && currentHolder != null) {
LocalDate prevStart = filteredStartDate.get(i - 1);
String prevHolder = holdingsMap.get(prevStart);
// 注意：prevHolder 可能为 null，需双重校验
if (prevHolder != null && currentHolder.equals(prevHolder)) {
isConsecutiveSame = true;
}
}
// 步骤3：根据状态执行业务逻辑
BigDecimal sum;
if (isConsecutiveSame) {
// 连续相同 holder：使用当前日期范围查询
sum = (BigDecimal) rdsSession
.createNativeQuery(DBQueries.GET_FLOAT_SHARES_BOTH_CONSOLIDATED_NON_CONSILIDATED)
.setParameter("investmentId", investmentId, StringType.INSTANCE)
.setParameter("startDate", currentStart, LocalDateType.INSTANCE)
.setParameter("endDate", currentEnd, LocalDateType.INSTANCE)
.getSingleResult();
} else {
// 首次出现 or holder变更 or 无前序holder：回退到基准起始日
LocalDate baseStart = filteredStartDate.get(0); // 或其他业务定义的基准日
sum = (BigDecimal) rdsSession
.createNativeQuery(DBQueries.GET_FLOAT_SHARES_BOTH_CONSOLIDATED_NON_CONSILIDATED)
.setParameter("investmentId", investmentId, StringType.INSTANCE)
.setParameter("startDate", baseStart, LocalDateType.INSTANCE)
.setParameter("endDate", currentEnd, LocalDateType.INSTANCE)
.getSingleResult();
}
restrictedHoldings.add(sum.longValue());
}⚠️ 关键注意事项
- 永远校验集合非空与索引范围：list.size() > 0 和 index >= 0 && index < list.size() 缺一不可；
- 避免 get(j-1) 类操作：除非明确 j > 0 且 j-1 在范围内，否则改用 Map 或预构建索引结构；
- 优先使用 Map 替代嵌套循环：O(1) 查找远优于 O(n×m)，尤其当 holdings 较小时效果显著；
- null 安全第一：holdings 表可能缺失某日期记录，get() 返回 null 是正常行为，需显式处理而非抛异常；
- 移除无意义的 break：原代码中 break 放在 if 外层，直接终止内层循环，导致匹配逻辑失效 —— 应仅在找到匹配项后 break。
✅ 总结
解决此类问题的核心原则是：分离关注点（遍历 vs 查找）、强化边界防护、用数据结构优化查找。不要让 i 和 j 的索引强行对齐，而应通过语义化映射（如 Map<日期, 持有人>）解耦关系。同时，所有 .get() 调用前必须确认索引有效性或对象非空，将防御性编程落实到每一行关键操作中。
