Java跑亿级报表OOM被开除？我靠达梦并行查询+虚拟线程分片拉取，3分钟出结果，DBA看懵了！

// 💥 翻车现场：经典“单线程+全量加载”的自杀式报表生成
String sql = “SELECT province, sum(amount), count(distinct user_id) FROM t_trade … GROUP BY province”;
List<Map<String, Object>> result = jdbcTemplate.queryForList(sql); // 💥 5亿行数据直接塞进 JVM 堆！
exportToExcel(result);

结果呢？SQL 刚发出去，达梦数据库的 CPU 单核直接打满 100%（其他 63 个核在看戏），跑了 20 分钟还没出结果。
接着，Java 端的 JVM 因为接收了海量的 ResultSet 数据，直接触发 Full GC，随后 java.lang.OutOfMemoryError: Java heap space，Pod 被 K8s 无情重启！

DBA 看着监控图冷笑：“Java 内存太小了，加机器！”
Java 开发拍桌子：“达梦太慢了，单核跑了 20 分钟，换个 Oracle Exadata 试试？”

我盯着达梦的执行计划和 Java 的 GC 日志，血压直接飙到 180。
我拍着他们的桌子吼：“你们这是在用单缸拖拉机去拉高铁的货啊！达梦服务器 64 个核，你们只让它跑 1 个线程；Java 端用单连接同步阻塞接收，网络带宽全被浪费！不用达梦的并行查询（Parallel Query），不用 Java 21 的虚拟线程做分片拉取，这报表跑到明年也出不来！”

那之后，我带着团队闭关一周，把达梦的并行执行引擎源码扒了个底朝天，结合 Java 2