唯一可靠路径是读取/proc/[pid]/task/[tid]/status，其中VmRSS字段最接近线程级物理内存占用，但含共享页；需用gettid()获取真实tid，不可用std::thread::id或pthread_t；须限频缓存、避免锁内读取、减少自身内存开销。
直接读 /proc/[pid]/task/[tid]/status 是唯一可靠路径
Linux 内核不提供 per-thread 的 RSS 或堆内存统计接口，/proc/[pid]/statm 和 /proc/[pid]/status 都只反映整个进程的聚合值。真正能区分线程粒度的，只有 /proc/[pid]/task/[tid]/status —— 它是内核为每个线程（LWP）单独维护的状态快照，其中 VmRSS 字段虽非严格“该线程独占”，但已是当前最接近线程级物理内存占用的可观测指标。
- 必须用目标进程的真实
pid+ 线程的tid（不是pthread_t）拼出路径，tid可通过gettid()获取，或从/proc/[pid]/task/目录遍历得到 -
VmRSS值仍含共享页（如 libc 数据段），但它比进程级VmRSS更敏感地反映线程私有栈增长、TLS 分配、以及该线程触发的 mmap 匿名页 - 不要尝试解析
/proc/[pid]/task/[tid]/smaps：该文件在多数内核版本中为空或与主线程内容完全一致，无实际区分意义
std::thread::id 无法映射到 tid，必须用 syscall(SYS_gettid)
标准 C++ 库不暴露线程 OS ID。std::this_thread::get_id() 返回的是实现定义的抽象标识，无法用于构造 /proc 路径。硬编码转换或哈希映射会彻底失效。
- 在线程启动函数入口处立即调用
syscall(SYS_gettid)并保存，这是唯一安全方式 - 若使用
std::thread构造，需将tid作为参数传入或通过线程局部存储（thread_local）缓存 - 注意：glibc 的
pthread_self()返回的是 pthread_t，不是 tid；两者数值通常不同，不能混用
高频采样时必须加限频和缓存，否则 CPU 开销爆炸
每次读取 /proc/[pid]/task/[tid]/status 触发一次内核态上下文切换和字符串解析，实测单次耗时 15–40 μs。若 10 个线程每 50ms 同时读取，仅此一项就可能吃掉 1%+ CPU。
- 对每个
tid实现滑动窗口限频：例如 1 秒内最多读 1 次，用std::chrono::steady_clock记录上次时间戳 - 缓存最近一次读取结果，除非明确需要实时值（如 OOM 前紧急诊断），否则不要每帧都刷
- 避免在锁区内读取：若监控逻辑嵌套在互斥量保护下，会显著拖慢关键路径；应改为异步采集 + 非阻塞更新
多线程监控本身会污染测量结果
你用来监控线程内存的代码，其自身分配（如 std::string 构造、std::regex 编译）也会计入被测线程的 VmRSS。尤其当监控线程与被测线程共享 arena 时，malloc 分配可能被归入同一 VMA。
- 用
std::string_view替代std::string解析status文件，避免额外堆分配 - 避免在采集路径中使用
std::regex；改用std::string::find()+std::stol()手动提取VmRSS:行 - 若需长期运行监控，考虑将采集逻辑剥离到独立监控线程，并用
pthread_setname_np()标记其名称，方便在top -H中识别干扰源
真实场景里，VmRSS 的波动往往比你想象中更剧烈——它包含栈帧、信号处理缓冲区、甚至内核为该线程预分配的页表项。别把它当精确值用，而是看趋势、比相对变化、盯异常尖峰。
