std::atomic是最轻量的进度同步方案，用于多线程更新UI进度条，保证load/store原子性且无锁无重排；需显式初始化、用store/load而非++、配合阈值控制更新频率，并注意溢出与平台限制。
std::atomic 是最轻量的进度同步方案多线程下更新 UI 进度条，核心矛盾是「写入线程非原子地改数值，读取线程看到撕裂值」。用 std::atomic<int></int> 能直接解决——它保证 load() 和 store() 是单指令、不可打断的操作，不需要锁，也没有内存重排风险。
- 进度变量声明为
std::atomic<int> progress{0};</int>，初始值必须显式初始化
- 工作线程里用
progress.store(value, std::memory_order_relaxed); 更新（std::memory_order_relaxed 足够，因为进度不要求严格顺序一致性）
- 主线程（如 Qt 的
QTimer 或 Win32 的消息循环）定时调用 progress.load() 读取，传给 UI 控件
- 别用
++progress 或 progress++：虽然原子，但会隐式触发 fetch_add，不如显式 store 清晰可控
std::mutex + condition_variable 适合需要响应“完成”事件的场景
如果进度条不仅要显示数字，还要在 100% 时触发弹窗或切换界面，光靠轮询 atomic 效率低、延迟高。这时得用条件变量唤醒主线程。
- 声明
std::mutex mtx; 和 std::condition_variable cv;，再配一个 std::atomic<bool> done{false};</bool>
- 工作线程结束前：
done.store(true);
cv.notify_one();
- 主线程等待时：
std::unique_lock<std::mutex> lk(mtx);
cv.wait(lk, []{ return done.load(); });
- 注意：
cv.wait 的谓词必须用 load()，不能直接写 done（否则编译不过）
- 不要用
notify_all：除非你真有多个等待线程，否则浪费唤醒开销
Qt 环境下别自己手写同步，优先用信号槽机制
Qt 的 QThread 和 QObject::moveToThread() 天然支持跨线程信号发射，比裸 C++ 原语更安全、更符合框架习惯。
- 把耗时任务封装成
QObject 子类，定义信号 void progressUpdated(int value); 和 void finished();
- 在工作线程中 emit 信号（Qt 自动序列化到接收对象所在线程）
- 主线程的 UI 对象 connect 这些信号，直接更新
QProgressBar::setValue()
- 关键点：发送对象和接收对象不能在同一个线程，否则信号变直接函数调用，失去线程隔离意义
- 如果用
std::thread 而非 QThread，需手动调用 QMetaObject::invokeMethod(..., Qt::QueuedConnection)，否则信号不进事件循环
进度值不是越大越好，注意溢出和重复更新
实际项目里常看到进度卡在 99% 或跳变严重，问题往往不在同步机制，而在业务逻辑本身。
立即学习“C++免费学习笔记（深入）”；
- 工作线程计算百分比时，用
static_cast<double>(current) / total <em> 100</em></double> 再转 int，避免整数除法截断（比如 99 / 100 100 == 0）
- 限制更新频率：UI 每秒刷新 30–60 次足够，没必要每次循环都
store。加个简单阈值判断：if (new_value > last_reported + 1) { progress.store(new_value); last_reported = new_value; }
- 避免在循环内频繁调用
load() 读取当前值做分支判断——这会把原子操作变成热点，反而拖慢工作线程
- 如果总任务量未知（流式处理），用「已处理字节数」代替百分比，UI 层自行决定是否显示为「xx MB / ？？」或估算剩余时间
Qt 的 QProgressBar 默认不显示具体数值，记得调用 setFormat("%p%")；Windows 的 SendDlgItemMessage 发 PBM_SETPOS 时，参数必须是 0–100 范围内的整数，超出会静默失败。
多线程下更新 UI 进度条，核心矛盾是「写入线程非原子地改数值，读取线程看到撕裂值」。用 std::atomic<int></int> 能直接解决——它保证 load() 和 store() 是单指令、不可打断的操作，不需要锁，也没有内存重排风险。
- 进度变量声明为
std::atomic<int> progress{0};</int>，初始值必须显式初始化 - 工作线程里用
progress.store(value, std::memory_order_relaxed);更新（std::memory_order_relaxed足够，因为进度不要求严格顺序一致性） - 主线程（如 Qt 的
QTimer或 Win32 的消息循环）定时调用progress.load()读取，传给 UI 控件 - 别用
++progress或progress++：虽然原子，但会隐式触发fetch_add，不如显式store清晰可控
std::mutex + condition_variable 适合需要响应“完成”事件的场景
如果进度条不仅要显示数字，还要在 100% 时触发弹窗或切换界面，光靠轮询 atomic 效率低、延迟高。这时得用条件变量唤醒主线程。
- 声明
std::mutex mtx;和std::condition_variable cv;，再配一个std::atomic<bool> done{false};</bool> - 工作线程结束前：
done.store(true); cv.notify_one();
- 主线程等待时：
std::unique_lock<std::mutex> lk(mtx); cv.wait(lk, []{ return done.load(); }); - 注意：
cv.wait的谓词必须用load()，不能直接写done（否则编译不过） - 不要用
notify_all：除非你真有多个等待线程，否则浪费唤醒开销
Qt 环境下别自己手写同步，优先用信号槽机制
Qt 的 QThread 和 QObject::moveToThread() 天然支持跨线程信号发射，比裸 C++ 原语更安全、更符合框架习惯。
- 把耗时任务封装成
QObject子类，定义信号void progressUpdated(int value);和void finished(); - 在工作线程中 emit 信号（Qt 自动序列化到接收对象所在线程）
- 主线程的 UI 对象 connect 这些信号，直接更新
QProgressBar::setValue() - 关键点：发送对象和接收对象不能在同一个线程，否则信号变直接函数调用，失去线程隔离意义
- 如果用
std::thread而非QThread，需手动调用QMetaObject::invokeMethod(..., Qt::QueuedConnection)，否则信号不进事件循环
进度值不是越大越好，注意溢出和重复更新
实际项目里常看到进度卡在 99% 或跳变严重，问题往往不在同步机制，而在业务逻辑本身。
立即学习“C++免费学习笔记（深入）”；
- 工作线程计算百分比时，用
static_cast<double>(current) / total <em> 100</em></double>再转int，避免整数除法截断（比如99 / 100 100 == 0） - 限制更新频率：UI 每秒刷新 30–60 次足够，没必要每次循环都
store。加个简单阈值判断：if (new_value > last_reported + 1) { progress.store(new_value); last_reported = new_value; } - 避免在循环内频繁调用
load()读取当前值做分支判断——这会把原子操作变成热点，反而拖慢工作线程 - 如果总任务量未知（流式处理），用「已处理字节数」代替百分比，UI 层自行决定是否显示为「xx MB / ？？」或估算剩余时间
Qt 的 QProgressBar 默认不显示具体数值，记得调用 setFormat("%p%")；Windows 的 SendDlgItemMessage 发 PBM_SETPOS 时，参数必须是 0–100 范围内的整数，超出会静默失败。
