在 Java 处理 Oracle 数据库的 CLOB 字段时，内存溢出问题虽常见却常被开发者忽略。许多人在面对大文本字段时，第一反应是使用 getClob().getSubString() 来读取，然而这种方式极易导致堆内存急剧膨胀，甚至引发 OOM。以下先给出几个关键判断：
直接调用 getClob().getSubString() 必须禁止
这是最常见也最危险的操作：即便 CLOB 仅 10MB，getSubString(1, (int) clob.length()) 也会强制驱动将整段内容加载进堆内存，再转换为 String。Java 中 char 占 2 字节，实际堆占用接近 20MB——而批量查询 100 条便会达到 2GB，java.lang.OutOfMemoryError: Java heap space 几乎必然发生。
更隐蔽的陷阱在于：clob.length() 在某些旧版 Oracle JDBC 驱动（如 11g 早期驱动）中本身就会触发全量 fetch，尚未读取内容，内存已经飙升。
- 永远不要在循环中对每个 CLOB 都调用一次
length()+getSubString() - 不要轻信“我只查几条，应该没事”——连接池复用与 GC 延迟会使 OOM 表现滞后且难以定位
- MyBatis 默认的
#{field}若未指定jdbcType=CLOB，可能悄悄回退到getString()，同样容易踩坑
getCharacterStream() 是唯一安全的读取入口
Oracle JDBC 驱动真正支持 LOB 指针语义的地方，其实隐藏在 getCharacterStream() 返回的 Reader 中。它不会加载全文，只按需从数据库拉取块数据（底层走 LOB locator + DBMS_LOB.READ），内存占用稳定在 KB 级别。
但必须配合 try-with-resources 使用，否则流不关闭会导致 LOB 句柄泄漏，Oracle 侧将持续持有连接和临时段。
- 缓冲区大小设为
8192足够，再大不会提升速度，反而增加单次分配压力 - 避免使用
BufferedReader.readLine()——CLOB 可能没有换行符，且readLine()内部缓冲不可控，易隐式放大内存 - 正确的写法是直接使用
reader.read(char[] buf)，按块处理，不拼接全文 - 字符集必须与数据库一致；若数据库使用 AL32UTF8，JDBC URL 需添加
&useUnicode=true&characterEncoding=UTF-8
ResultSet 的游标类型决定流是否有效
Oracle CLOB 流的生命周期绑定在当前 ResultSet 行和底层连接上。在默认 TYPE_FORWARD_ONLY 下，只要调用一次 rs.next()，前一行的 Reader 立即失效，再读取就会抛出 SQLException: Stream has already been closed。
这并非代码 bug，而是 JDBC 游标语义的体现。强行 catch 并重试只会掩盖问题。
- 最简方案：所有 CLOB 处理逻辑必须在
while(rs.next()) { ... }当前行内完成 - 若需跨行访问（如分页时缓存多行 CLOB），必须显式创建
ResultSet时传入ResultSet.HOLD_CURSORS_OVER_COMMIT（Oracle 12.1+ 驱动才可靠支持） - 不要依赖
Connection.setHoldability()全局设置——MyBatis / Druid 等框架可能覆盖它
隐式 LOB 缓存会悄悄破坏流式语义
Oracle JDBC 驱动默认开启 implicitCachingEnabled=true，这意味着即使你只调用了一次 clob.getSubString(1,1) 或 clob.length()，驱动就有可能将整个 LOB 缓存在本地内存中，后续 getCharacterStream() 实际读取的是缓存副本——内存占用照涨，流式处理形同虚设。
现象是：jmap -histo 显示大量 [C（char[]）实例，但代码里根本没有存储 String。
- 解决办法：在 JDBC URL 中显式关闭，添加
&implicitCachingEnabled=false - 验证方式：在测试中注释掉所有
length()和getSubString()调用，观察内存曲线是否平稳 - MyBatis 用户注意：自定义
TypeHandler中若使用了clob.length()判空，必须删除，改用clob == null直接判断
