面向对象不提供并行擦写能力，真正实现依赖多线程调度、内存布局与零开销抽象；通过FillJob和ParallelFiller类封装分块擦写逻辑，复用模板数组、静态工厂及Unsafe/VarHandle优化，规避虚调用、对象分配与反射等性能陷阱。
面向对象本身不直接提供“并行擦写”能力，它只是组织代码的范式；真正实现高性能像素矩阵并行擦写的，是底层的多线程调度、内存布局设计与零开销抽象，而面向对象可用来封装这些机制，使其安全、可复用、易维护。
用类封装分块+多线程擦写逻辑
把“按区域填色”这一动作建模为一个可配置、可复用的对象，避免每次擦写都手写线程调度：
- 定义 FillJob 类：持有目标像素数组（
int[] pixels）、起始偏移、长度、目标颜色值（如0xFF000000），提供run()方法执行Arrays.fill(pixels, offset, offset + length, color) - 定义 ParallelFiller 类：接收像素数组、线程池（如
ForkJoinPool.commonPool()或固定大小池）、块大小（如每块 65536 个像素），自动切分并提交多个FillJob - 关键点：所有实例字段在构造时确定，无运行时状态变更，避免同步开销
复用模板数组 + 不可变填充策略
面向对象支持“行为封装”，但高性能擦写必须规避对象创建和冗余计算：
- 声明 static final int[] BLACK_BLOCK、WHITE_BLOCK 等预填充模板数组（长度对齐至 16 的倍数），由
ParallelFiller直接复用 - 不提供
setFillColor(int c)这类 setter，而是通过工厂方法生成专用 filler：ParallelFiller.forColor(0xFF000000)，返回已绑定颜色的实例 - 避免在擦写过程中调用 getter/setter 或虚方法——热点路径应内联，JVM 对 final 方法和 static 工厂更友好
结合 Unsafe 或 VarHandle 实现零抽象损耗
面向对象不排斥底层优化；可通过私有工具类隐藏不安全操作，对外保持干净接口：
- 内部使用
Unsafe.putInt()或VarHandle（JDK9+）批量写入，跳过数组边界检查 - 将 Unsafe 访问封装在 UnsafeFiller 类中，仅在类静态初始化块里获取实例，不暴露原始指针
- 对外仍通过
fill(pixels, color)调用，调用方无需知道是用了 arraycopy 还是 Unsafe——这是面向对象的封装价值
避免常见 OOP 性能陷阱
很多“面向对象实现”反而拖慢渲染，因误用抽象层级：
- 不用
interface FillStrategy+ 多个实现类做运行时选择——分支预测失败、虚调用开销；改用编译期泛型或配置常量区分模式 - 不把每个像素当作
Pixel对象（会触发百万级对象分配和 GC），始终操作原始数组或 buffer 视图 - 不依赖反射、动态代理、Spring Bean 管理 filler 实例——启动快、热加载无关、无代理对象逃逸
