UI 程序退出卡顿问题分析：从真实案例深入理解退出清理路径负载问题

---

📖 推荐阅读：《Yocto项目实战教程:高效定制嵌入式Linux系统》
🎥 更多学习视频请关注 B 站：嵌入式Jerry

---

UI 程序退出卡顿问题分析：从真实案例深入理解退出清理路径负载问题

在 UI 程序开发中，我们经常遇到一种现象：点击窗口关闭按钮（如右上角 “×”）后，界面不会立即消失，存在明显卡顿甚至几秒的延迟。本文将通过一个市场上真实的 C++ 多线程项目案例，从现象到分析，再到精确定位和优化，完整剖析 UI 程序退出时“清理路径”负载过重导致延迟的问题。

---

一、问题现象与背景

背景介绍

• 平台：定制 Linux 系统 + ARM 开发板
• UI框架：自主 C++ Qt 类似框架（非 FLTK）
• 编程语言：C++
• 场景：后台多个线程接收传感器数据并绘图，窗口关闭后界面卡顿 2 秒

问题描述

在点击 UI 主窗口的“×”按钮后，窗口没有立刻退出，而是卡顿 2 秒后程序才完全关闭。

---

二、初步定位手段：strace + perf

使用 strace 追踪关闭路径：

strace -tt -f -o close_ui.log ./realtime_monitor

分析长时间调用：

awk '{if($NF~/>/)print $0}' close_ui.log | sort -k1,1 | tail -n 50

发现大量 munmap(), futex(), poll(), close() 系统调用在退出阶段出现。

使用 perf 分析 CPU 栈：

perf record -g -p $(pidof realtime_monitor)
perf report

perf 报告显示 exit_mmap()、do_exit() 和 unmap_vmas() 占用较高。

---

三、真实项目定位：线程阻塞导致 UI 卡顿

程序逻辑简述：

int main() {
    std::thread net_reader(read_data_thread);
    std::thread plot_updater(update_ui_thread);
    return run_event_loop();
}

void cleanup() {
    running = false;
    net_reader.join();
    plot_updater.join();
    printf("Cleanup done\n");
}

关键问题

关闭窗口后，主线程等待两个后台线程退出。但后台线程使用 epoll 和 futex 等阻塞式同步机制未能及时结束，导致 join() 卡顿，进而延迟 exit() 阶段。

---

四、函数路径与源代码分析

文件：src/data/read_data.cpp

void read_data_thread() {
    while (running) {
        epoll_wait(epfd, events, MAX_EVENTS, 1000); // 阻塞
    }
}

文件：src/ui/update_ui.cpp

void update_ui_thread() {
    while (running) {
        std::unique_lock<std::mutex> lock(ui_mutex);
        cond_var.wait(lock);  // 阻塞
    }
}

由于没有中断机制，线程在阻塞状态下不能响应 running = false，导致 join() 卡死直到超时或 epoll 返回。

---

五、优化方案

✅ 方案一：事件触发唤醒阻塞线程（推荐）

int eventfd = eventfd(0, 0);
// 添加到 epoll
epoll_ctl(epfd, EPOLL_CTL_ADD, eventfd, &ev);

// 停止线程时：
uint64_t val = 1;
write(eventfd, &val, sizeof(val));

确保 epoll 立刻返回，线程可退出。

✅ 方案二：条件变量带超时

cond_var.wait_for(lock, std::chrono::milliseconds(100));

避免永久阻塞，提高退出响应速度。

✅ 方案三：主线程不等待所有子线程（不推荐）

net_reader.detach();

可能引发资源未释放问题，仅适合非关键线程。

---

六、业界类似案例

Chromium 多线程 UI 卡顿

Chromium 项目中 UI Thread、IO Thread、GPU Thread 协作复杂。关闭时如果未统一管理线程退出，会导致延迟或资源未清理。Google 使用 TaskRunner + Thread::StopSoon() 实现优雅退出。

ROS2 多线程节点退出卡顿

在 ROS2 中，节点使用多个线程订阅话题，如果未添加 rclcpp::shutdown() 中断 spin，退出会卡在 join()。后续版本优化中引入 signal-safe 的线程通知机制。

---

七、问题逻辑图总结

[点击 ×]
  ↓
主线程 exit → join(worker)
  ↓
worker 卡在 epoll/futex/poll
  ↓
exit_mmap → 资源释放延迟 → 卡顿

---

八、结语与建议

UI 卡顿问题归根结底是“退出清理路径负载过重”或“线程阻塞未能及时响应”。建议：

• 所有线程必须具备 可中断机制（事件/信号/超时）
• 尽量避免在主线程 join() 阻塞
• 使用 perf + strace 精准定位卡顿路径

避免将 UI 卡顿误判为图形性能问题，退出路径同样值得重视。

---

---

📖 推荐阅读：《Yocto项目实战教程:高效定制嵌入式Linux系统》
🎥 更多学习视频请关注 B 站：嵌入式Jerry

---