构造代码块不适用于对象池化场景，因其仅在new时执行一次，无法满足复用对象需每次重置状态的要求；真正有效的是由池管理器显式调用的幂等reset()方法。
直接用构造代码块（instance initializer block）无法安全实现对象池化下的变量重置——它只在 new 实例时执行一次，而池化要求对象被反复复用、每次归还后都需重置状态。真正在池中起作用的，是显式设计的 reset() 方法，配合生命周期管控。
为什么构造代码块不适用池化场景
构造代码块随构造函数一同运行，属于对象创建阶段的初始化逻辑。在对象池中，对象只创建一次，后续借用/归还全程不 new，因此构造代码块不会再次触发。若依赖它来“重置”，实际只会生效第一次，之后所有复用都带着脏状态。
- 构造代码块：仅在 new 时执行 → 池中对象一生只跑一次
- reset() 方法：由池管理器显式调用 → 每次归还前或借出后均可执行
- 典型错误：把清空逻辑写在构造块里，误以为“每次取出来就自动重置”
真正有效的重置实践：以 StringBuilder 为例
StringBuilder 是池化高频对象的典型代表。它的重置核心是 setLength(0) —— 不新建、不清数组、只改长度计数器，毫秒级零分配。
- 底层原理：
setLength(0)仅将内部count字段置为 0，char[] 数组保留且内容未擦除，后续append()直接覆盖旧字符 - 对比方案：
delete(0, sb.length())仍走校验 + arraycopy；new StringBuilder()触发 GC - 线程安全前提：必须确保同一实例不被多线程并发读写，推荐搭配 ThreadLocal 或单线程池使用
带 reset() 的可池化类标准写法
自定义业务对象池化时，应提供明确、幂等、无副作用的 reset() 方法，并在池管理流程中强制调用：
- 字段逐个恢复默认值：基本类型设 0/false，引用类型设 null（或清空集合）
- 避免残留引用：如 List、Map 等容器，调用
clear()而非 new 新实例 - 不依赖 finalize / 析构：JVM 不保证及时调用，池中对象生命周期由代码严格控制
- 示例结构：
private byte[] data;
private int offset;
private boolean valid;
public PooledBuffer(int capacity) {
this.data = new byte[capacity];
}
public void reset() {
this.offset = 0;
this.valid = false;
// data 数组复用，不 new，不清零字节（除非协议要求）
}
}
池管理器中 reset 的关键调用时机
reset 不是“可选优化”，而是池协议的硬性环节。必须嵌入 borrow / return 流程：
- 借出时重置（更安全）：防止上一使用者残留数据影响当前调用
- 归还时重置（更常见）：由使用者调用
returnToPool(obj)内部触发obj.reset() - ThreadLocal 池典型模式：
public static StringBuilder borrow() {
StringBuilder sb = TL.get();
sb.setLength(0); // 关键：每次借出前强制重置
return sb;
}
