Oracle CLOB高效读取需用getCharacterStream()流式读取、设合适fetchSize、严格管理Reader生命周期，避免toString()或getClob()导致OOM。
Oracle CLOB读取慢，多数是因为没用对 getCharacterStream()
直接调用 getClob() 再转字符串，或用 toString()，是常见性能陷阱。Oracle JDBC 驱动对 Clob 对象的 toString() 实现会把整个内容加载进内存并转成 String，哪怕 CLOB 有几十 MB，也会触发 Full GC 或 OOM。
真正高效的方式是绕过中间对象，用流式拉取：
-
ResultSet.getCharacterStream("column_name")返回Reader，可按需读取，内存占用恒定 - 若字段可能为空，先用
wasNull()判断，避免NullPointerException - 不要用
BufferedReader.readLine()处理超长单行 CLOB（比如 XML/JSON），它内部缓存行为不可控；改用char[]批量读取更稳
批量读取大 CLOB 时，必须设置 setFetchSize()
Oracle 默认 fetchSize = 10，查 100 行带 CLOB 的记录，驱动会分 10 次网络往返拉取 CLOB 数据（每次只拉当前 fetch batch 中的 CLOB），实际 I/O 放大 10 倍。
解决方法很简单，在执行前显式设置：
立即学习“Java免费学习笔记（深入）”；
PreparedStatement ps = conn.prepareStatement("SELECT id, content FROM docs WHERE status = ?");
ps.setFetchSize(50); // 和业务单次处理量匹配，别盲目设 1000+
ResultSet rs = ps.executeQuery();
注意：setFetchSize() 必须在 executeQuery() 之前调用，之后调无效；且对 CLOB 流式读取生效的前提是：JDBC URL 中未启用 SetBigStringTryClob=true（该参数会让驱动自动把 setString() 转 CLOB，但会干扰流式读取逻辑）。
遇到 “Stream has already been closed” 错误，大概率是 ResultSet 提前关闭了
CLOB 的 Reader 是懒加载、强依赖 ResultSet 生命周期的。一旦 rs.close() 或 rs.next() 移动到下一行，上一行的 CLOB 流就失效。
典型翻车场景：
- 在
while(rs.next())循环里拿到Reader，但没当场消费完，留到循环外处理 - 用 try-with-resources 自动关
ResultSet，但把Reader存到集合里延后读 - Spring JdbcTemplate 默认关闭
ResultSet，直接 returngetCharacterStream()必报错
正确做法：在 rs.next() 当次循环内完成全部读取，或把 CLOB 内容拷贝成 String/StringBuilder（仅限确定不超 1MB 的场景）。
Java 8+ 可用 readAllBytes() 简化小 CLOB 读取，但别滥用
如果确认 CLOB 总是小于几 MB，且业务允许短时内存占用，可以用 JDK 自带的便捷方式：
Reader reader = rs.getCharacterStream("content");
String content = new String(reader.readAllBytes(), StandardCharsets.UTF_8);
这比手动写 char[] 循环简洁，但要注意：
-
readAllBytes()底层仍会把全部内容读入内存，和getClob().getSubString(1, (int) clob.length())本质一样，只是少写几行 - Oracle CLOB 字符集可能不是 UTF-8（比如数据库是 AL32UTF8），需用
clob.getCharacterStream()+ 显式指定 charset 的InputStreamReader更稳妥 - 若 CLOB 含 BOM 或换行符不规范，
readAllBytes()不做任何清洗，后续解析 XML/JSON 可能失败
CLOB 的“高效”从来不是指代码行数少，而是让 IO、内存、GC 三者可控——流式读取 + 合理 fetchSize + 严格生命周期管理，缺一不可。
