不能直接用setBlob()/getBlob()传整个byte[]，因Oracle JDBC驱动会全量加载LOB到JVM堆导致OOM，且ResultSet关闭后Blob流即失效；写入需先insert empty_blob()再for update获取oracle.sql.BLOB写入；读取须用getBinaryStream()分块处理。
为什么不能直接用 setBlob() 或 getBlob() 传整个 byte[]
因为 oracle jdbc 驱动（尤其 ojdbc6/ojdbc8 早期版本）对 setblob(int, blob) 和 getblob() 的实现依赖临时 lob 定位符和客户端内存缓冲，一旦 blob 超过几 mb，blob.getbytes(1l, (int) blob.length()) 就会把全部二进制数据加载进 jvm 堆，极易触发 outofmemoryerror。更隐蔽的问题是：某些驱动在 resultset 关闭后立即使 blob 对象失效，后续调用 getbinarystream() 抛 sqlexception: stream has already been closed。
写入 BLOB 必须先插入 empty_blob() 再 for update
Oracle 不允许对未初始化的 BLOB 字段直接写入流——必须分两步走：
- 第一步：用
INSERT INTO table(col) VALUES (empty_blob())占位，且Connection必须设为autoCommit = false - 第二步：用
SELECT col FROM table WHERE id = ? FOR UPDATE查询并加行锁；不加FOR UPDATE会报row containing the LOB value is not locked - 从
ResultSet中取oracle.sql.BLOB（不是java.sql.Blob），调getBinaryOutputStream()写入，**务必在executeUpdate()提交前完成流写入与关闭** - 若用 HikariCP 等连接池，
OutputStream关闭必须在PreparedStatement.executeUpdate()返回之后，否则驱动可能复用连接导致流中断
读取 BLOB 应始终用 getBinaryStream() 分块拉取
别碰 blob.getBytes()，哪怕你确认 blob 只有 10MB —— 驱动内部仍可能全量缓存。安全做法是：
- 调
rs.getBlob("col").getBinaryStream()获取InputStream，它底层走的是 Oracle 的流式协议，不占堆内存 - 用固定大小缓冲区（如
byte[8192]）循环read()，每次处理一块，避免一次性转成byte[]或String - 必须在当前
ResultSet行内完成全部读取；移动到下一行（rs.next()）后，前一行的流立即失效 - 若需转存文件或响应 HTTP 流，直接用
IOUtils.copy(is, outputStream)（Apache Commons IO），它内部就是分块逻辑，无需自己写 while
ojdbc 版本和连接参数影响流行为
ojdbc6 对 getBinaryStream() 返回的流不支持 mark()/reset()，且默认关闭流时不会通知数据库释放 LOB 句柄；ojdbc8 改进明显，但仍需注意：
- 连接 URL 加
;defaultRowPrefetch=100;oracle.jdbc.defaultLobPrefetchSize=32768可减少 LOB 定位符网络往返 - 批量写入多个 BLOB 时，禁用
addBatch()，改用单条PreparedStatement+ 手动事务控制，否则每条都会触发独立 LOB 分配 - 极端场景（如百万级小 blob 插入），应绕过 JDBC，用 SQL*Loader 或 Oracle 的
UTL_FILE+ PL/SQL 批量载入
最易被忽略的一点：所有流操作（InputStream / OutputStream）的生命周期必须严格绑定在对应 ResultSet 和 Connection 的有效期内，跨作用域传递流对象几乎必然失败。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
