Java 17读Oracle CLOB变慢的根源是默认启用严格流资源校验，getCharacterStream()返回的Reader被包装为close-on-finalize代理，未显式关闭或未用try-with-resources会导致游标延迟释放、rs.next()阻塞、读取耗时骤增数十秒；必须用try-with-resources、固定缓冲区8KB、禁用br.lines().forEach、优先选getCharacterStream()而非getAsciiStream()、避免getSubString、禁止跨行复用CLOB流、CLOB流生命周期严格绑定ResultSet和Connection。
为什么 Java 17 读 Oracle CLOB 突然变慢了
不是驱动退化，也不是 jvm bug，而是 java 17 默认启用了更严格的流资源校验——getcharacterstream() 返回的 reader 在底层被包装为带 close-on-finalize 的代理对象，若未显式关闭或未用 try-with-resources，jdbc 驱动会延迟释放数据库侧游标资源，导致后续 rs.next() 阻塞、clob 流卡住、读取耗时从毫秒级跳到几十秒。尤其在连接池复用场景下，这个问题会被放大。
getCharacterStream() 必须配合 try-with-resources 使用
Java 17 下不写 try-with-resources，等于没关流。即使手动调 reader.close()，也容易漏掉异常分支；而 br.close() 又可能抛出 IOException 掩盖原始 SQLException。
-
try(Reader reader = rs.getClob("content").getCharacterStream())是底线，不能省 - 缓冲区大小建议固定为
8192（8KB），再大不提速，反而多占堆 - 别用
br.lines().forEach(...)：它内部会预加载全部行到内存，彻底破坏流式语义 - 若需全文拼接，用
StringWriter+IOUtils.copy(reader, writer)，别自己 while 循环 append char[]
getCharacterStream() vs getAsciiStream()：选错就乱码
Oracle JDBC 驱动对两个流的编码处理完全不同：
-
getClob().getCharacterStream()→ 返回Reader，由 JDBC 驱动按连接字符集（如 UTF-8）解码，中文安全，推荐首选 -
getClob().getAsciiStream()→ 返回InputStream，只做字节转发，不自动解码；若数据库存的是 UTF-8 中文，用它读就会乱码 - 绝对不要调
getClob().getSubString(1, (int) clob.length())：这一步已全量加载进堆，OOM 风险照旧，和 Java 版本无关
ResultSet 移动导致 CLOB 流失效的隐藏陷阱
Oracle 默认 ResultSet.TYPE_FORWARD_ONLY，一旦执行 rs.next()，上一行的 CLOB 流立即作废——Java 17 报错更早、更明确：SQLException: Stream has already been closed。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 必须在当前行内完成全部读取，不能跨行缓存
Reader - 若业务真需跨行访问，创建
Statement时加参数：conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY)，并确认驱动版本 ≥ 12.1 - 别依赖
setFetchSize()来“优化”CLOB 查询：它只影响行批量拉取，对单个 CLOB 的流式读取无实质帮助
最常被忽略的一点：CLOB 流的生命期完全绑定于 ResultSet 和 Connection，只要其中任一者提前 close，流立刻不可用——这不是 Java 17 特有，但它的错误提示更直白，逼你面对这个老问题。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
