clear() 不清空数据，仅重置 position=0、limit=capacity、mark=-1，敏感字节仍残留于底层数组，存在内存泄露风险；应手动擦除（如 arrays.fill(buffer.array(), (byte)0)）或避免在复用 buffer 中存储明文敏感信息。
Java NIO 中 Buffer.clear() 方法只是重置位置（position）和限制（limit），并不清空底层数组中的实际字节内容。这意味着敏感数据（如密码、密钥、令牌等）仍驻留在堆内存中，可能被后续操作意外读取，或在堆转储（heap dump）分析时暴露，构成侧信道泄露风险。
clear() 的真实行为：仅重置指针，不擦除数据
clear() 本质是执行：
position = 0limit = capacitymark = -1
底层 byte[] 或堆外内存中的原始字节保持原样。如果该 Buffer 曾写入过密码明文（例如通过 put(String.getBytes())），这些字节仍存在于数组中，直到被新数据覆盖或 GC 回收——而 GC 不保证立即覆写或清零内存。
哪些场景容易触发泄露
以下情况尤其危险：
- 复用同一
ByteBuffer处理多个请求，且中间未显式擦除敏感字段 - 将含敏感数据的 Buffer 传入日志框架（如 toString() 触发数组内容打印）
- 应用发生 OOM 或主动导出 heap dump 用于调试，攻击者可离线解析内存镜像提取残留明文
- 使用堆外内存（
ByteBuffer.allocateDirect()）时，JVM 不控制其初始化值，旧数据更可能残留
安全替代方案：主动擦除 + 合理生命周期管理
关键原则：敏感数据“用完即焚”，而非依赖 GC 或 clear()。
- 对堆内
ByteBuffer，获取底层数组后手动清零：if (buffer.hasArray()) { Arrays.fill(buffer.array(), (byte) 0); } - 对堆外
ByteBuffer，无法直接访问数组，应使用Unsafe.setMemory()（需权限）或改用java.security.SecureRandom覆盖；更稳妥的是避免在 Direct Buffer 中存放敏感明文 - 优先使用
char[]或byte[]承载敏感信息，并在使用后立即调用Arrays.fill(arr, (char) 0)—— 这比 String 更可控（String 不可变且可能被 intern） - 限制 Buffer 生命周期，避免跨请求复用；必要时每次分配新实例，配合 try-with-resources 或显式清理逻辑
工具与检查建议
可在开发和测试阶段引入防护措施：
- 静态扫描：用 SpotBugs 或 Semgrep 检测
clear()后未擦除敏感数据的模式 - 运行时监控：对关键 Buffer 分配点添加包装类，记录是否已标记为“需擦除”，并在 finalize 或 close 时强制清零（注意：不依赖 finalize）
- 安全编码规范中明确禁止将密码类字符串直接写入可复用 Buffer，要求必须经加密/哈希后再传输
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
