嘿，我来帮你拆解这个问题——处理百万级ResultSet时UI偶尔冻结，哪怕用了SwingWorker，对吧？这种场景我之前踩过不少坑，大概率是JDBC配置或者后台处理的细节没做到位，咱们一步步来解决：

1. 先搞定JDBC的Fetch Size配置（最关键！） #

MySQL Connector/J默认的行为是一次性把所有查询结果加载到客户端内存，哪怕你用ResultSet.next()逐行读取，其实数据早就全存在本地了。百万行数据的话，内存占用会瞬间飙升，轻则触发频繁的GC停顿（Full GC会暂停所有线程，包括EDT），重则直接OOM，这就是UI偶尔冻结的核心原因之一。

解决办法很明确：

• 首先在JDBC连接URL中开启服务器端游标：jdbc:mysql://your-host/your-db?useCursorFetch=true
• 然后在创建Statement/PreparedStatement时设置合适的Fetch Size，比如1000或5000（根据你的内存情况调整）：

// 创建仅向前、只读的Statement（进一步减少内存开销）
PreparedStatement stmt = conn.prepareStatement(
    yourSql,
    ResultSet.TYPE_FORWARD_ONLY,
    ResultSet.CONCUR_READ_ONLY
);
stmt.setFetchSize(1000); // 每次从服务器拉1000行数据
ResultSet rs = stmt.executeQuery();

这样驱动会用服务器端游标分批拉取数据，客户端内存占用会大幅降低，GC压力也小很多。

2. 优化SwingWorker的处理逻辑 #

虽然你说避开了EDT，但有些细节容易忽略：

• 不要频繁调用publish()：如果每处理一行就调用一次publish，大量的UI更新请求会堆积在EDT队列里，导致UI卡顿。建议攒一批数据再发布，比如每处理1000行调用一次publish，在process()方法里批量更新UI。
• 避免在doInBackground()中创建UI对象：哪怕是间接的，比如创建Swing组件或者调用UI相关的工具类，都可能不小心触发EDT的阻塞。所有UI操作必须放在process()或者done()方法里。
• 监控SwingWorker的执行状态：如果后台任务偶尔出现长时间阻塞（比如数据库临时卡顿），可以考虑给UI加个超时提示，或者用进度条让用户感知到任务在运行，避免误以为UI冻结。

3. 数据处理的内存优化 #

百万行数据处理很容易产生内存堆积：

• 及时释放无用引用：处理完一行ResultSet后，不要保留该行的对象引用，让GC能及时回收。比如不要把所有行的数据都存在List里，而是处理一行就丢弃一行（如果不需要保存全部数据的话）。
• 减少对象创建：尽量用基本类型代替包装类，复用常用对象（比如用对象池处理频繁创建的实体类），避免频繁的小对象创建导致的Minor GC频繁触发。
• 用内存分析工具排查：比如用VisualVM监控JVM的内存使用和GC情况，看看有没有内存泄漏或者异常的内存峰值，针对性优化。

4. 数据库查询本身的优化 #

有时候问题出在查询端：

• 只查需要的列：别用SELECT *，明确写出需要的字段，减少数据传输量和客户端内存占用。
• 添加合适的索引：如果查询本身在数据库端耗时太长，后台任务会一直占用资源，间接影响UI响应。确保查询的过滤条件、排序字段都有索引。
• 考虑分批查询：如果服务器端游标还不够，可以手动分页查询，比如每次查LIMIT 10000 OFFSET xxx，处理完一批再查下一批，进一步降低客户端压力。

总结下来，最可能的问题是：

1. 没有配置MySQL的useCursorFetch=true和合适的fetch size，导致一次性加载全量数据到客户端，引发GC停顿。
2. SwingWorker的publish()调用过于频繁，导致EDT被大量更新任务阻塞。
3. 数据处理时没有注意内存管理，导致频繁GC或者内存堆积。

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