必须传图像指针或引用而非值传递，用std::shared_ptr管理生命周期；按高度分块并行处理，每线程写自有行区间；优先使用cv::parallel_for_实现高效滤镜并行化。
子线程中直接操作图像内存，别拷贝
图像数据通常很大，主线程传 std::vector<pixel></pixel> 或 Image 对象进子线程，若用值传递会触发深拷贝，640×480 的 RGB 图像就占约 921KB，拷贝本身耗时可能超过滤镜计算。必须传指针或引用，且确保主线程在子线程运行期间不修改或释放该内存。
常见错误现象：
- 滤镜结果偶尔错乱或崩溃 → 主线程提前 delete 图像对象，子线程访问野指针
- 多个子线程同时写同一块内存 → 颜色通道被交叉覆盖（尤其没加锁时）
实操建议：
- 用 std::shared_ptr<image></image> 管理图像生命周期，子线程持有一份引用计数
- 若只读（如灰度化、卷积核计算），子线程可安全并发读；若写（如亮度调整），必须按行/区块划分写区域，避免跨线程写同一 Pixel
- 不要用 std::thread 直接捕获局部变量地址，改用 std::async + std::launch::async 显式控制启动时机
按高度分块并行，不是按像素
对每个像素开线程是灾难性的——线程创建/切换开销远超计算本身。正确做法是把图像按高度方向切分成 N 个连续行区间（例如 4 线程就切为 top / upper / lower / bottom 四段），每段由一个子线程处理。
使用场景：
- 适用于所有逐像素独立运算的滤镜：亮度、对比度、灰度、锐化、卷积（边界已预填充）
- 不适用于需全局统计的滤镜（如直方图均衡化），那种得先单线程扫一遍再分发
实操建议：
- 切分点用整数行号，避免浮点误差： int start_row = (height * tid) / thread_count;
- 每个线程处理范围为 [start_row, end_row)，end_row 由下一段起点决定，最后一段补到 height
- 卷积类滤镜若需邻域（如 3×3），切块时上下各留 radius 行作重叠区，或提前在图像外扩边界（推荐镜像填充）
避免 mutex 锁整张图，改用无锁分片写入
如果所有子线程都往同一个 Image 对象里写，又用一个 std::mutex 保护整个 setPixel()，那实际是串行执行，还多了锁开销。真正高效的写法是让每个线程只写自己负责的行区间，完全不冲突。
参数差异：
- 原始 Image::setPixel(int x, int y, const Pixel&) 是线程不安全的
- 改为线程安全版本需加检查：仅当 y 在本线程责任范围内才允许写，否则断言失败或跳过
实操建议：
- 子线程函数签名类似：void processBlock(Image& img, int start_y, int end_y, const FilterConfig& cfg)
- 内部循环直接用 img.pixels[y * width + x] 赋值，绕过 setPixel() 的边界检查（已在分块时保证合法）
- 若必须复用原有接口，可在构造 Image 时标记为「多线程写模式」，关闭运行时坐标校验（仅调试版开启）
OpenCV 的 cv::parallel_for_ 是最简方案
手写线程池+分块容易出错，而 OpenCV 内置的 cv::parallel_for_ 已封装好负载均衡、线程复用和缓存友好访问模式，一行代码就能并行化滤镜循环。
性能影响：
- 在 4 核 CPU 上，cv::medianBlur 并行版比单线程快 3.2×，而手写线程池若未对齐 cache line 可能只快 1.8×
- cv::parallel_for_ 自动适配逻辑核心数，不硬编码线程数
实操建议：
- 封装滤镜为 cv::ParallelLoopBody 子类，operator() 实现某行区间的处理逻辑
- 调用时传入 cv::Range(0, image.rows)，OpenCV 自动切分
- 注意：输入 cv::Mat 必须是连续内存（mat.isContinuous() == true），否则需先 clone()
容易被忽略的地方：图像宽不是 16 字节对齐时，SIMD 指令（如 AVX2）可能因地址未对齐而降级为慢速路径——这比线程同步开销更隐蔽，也更难调试。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
