应使用 getcharacterstream() 流式读取 clob，先判空再获取 reader 循环读取，禁用 readline()，读完调用 free() 防泄漏；避免 getstring() 导致截断或 npe。
Java 中通过 JDBC 读写 Oracle 的 CLOB 字段，核心是绕开字符串全量加载、避免内存溢出（OOM），并正确管理流和连接生命周期。关键不在“能不能”，而在“怎么用对”。
读取 CLOB：别用 getString()，优先走 getCharacterStream()
ResultSet.getString("col") 对 CLOB 不安全——可能截断（如驱动默认 4000 字节阈值）、返回 null 或空串，尤其字段为 NULL 时易抛 NPE。
- 改用 rs.getClob("col") 获取 Clob 对象，先判空：
if (clob != null) - 调用 clob.getCharacterStream() 得到 Reader（不是 InputStream！）
- 用固定缓冲区（如
char[8192]）循环读取，禁用 readLine() 和 lines()（会缓存整行，破坏流式初衷） - 读完建议显式调用 clob.free()（JDBC 4.0+），防止连接池中 LOB 句柄泄漏
- 若确定内容较短（IOUtils.toString(clob.getCharacterStream(), StandardCharsets.UTF_8)
写入 CLOB：别用 setString()，用 setCharacterStream() 或 setClob()
PreparedStatement.setString() 写超长文本会触发 ORA-01461 错误——驱动试图塞进 VARCHAR2 绑定槽，而非 CLOB。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 推荐方式一：ps.setCharacterStream(paramIndex, reader, length)，让驱动内部处理 CLOB 分配，无需手动创建 Clob 对象
- 推荐方式二：用 conn.createClob() 创建临时 Clob，
clob.setString(1, content)写入，再ps.setClob(paramIndex, clob) - 若用 setCharacterStream，确保 reader 编码与数据库字符集一致（如 AL32UTF8），否则乱码
- Oracle 12.1+ 驱动可启用 SetBigStringTryClob=true 连接参数，使 setString() 自动降级为 CLOB 绑定（需 ojdbc8+）
批量操作 CLOB：关自动提交，防事务膨胀
每个 CLOB 插入都会分配 LOB 定位符并单独传输，addBatch() 默认逐条执行，性能极差。
- 必须 conn.setAutoCommit(false)，所有 batch 执行完再统一 commit()
- 循环内复用 Connection 和 PreparedStatement，避免反复获取连接
- 每条记录仍需独立 createClob() + setString()，但不要在循环里重新 getConnection()
- 百万级插入应考虑 SQL*Loader 或服务端 DBMS_LOB 调用，绕过 JDBC 层
常见陷阱与规避
很多 OOM 和异常其实源于细节疏忽：
- clob.getSubString(1, (int)clob.length()) 会把整个内容加载进堆内存，几 MB 就可能 OOM；超 2GB 直接抛 SQLException
- clob.toString() 返回的是对象哈希码，不是内容，千万别当字符串用
- 使用 HikariCP 等连接池时，setCharacterStream 的 Reader 必须保持打开，直到 executeUpdate() 完成
- 某些旧驱动对 clob.length() 的调用本身就会触发全量加载，不确定大小时直接流式读取更稳妥
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
