C++ vector size与迭代器遍历次数不符问题求助

嘿，我来帮你分析下这个问题——从你提供的日志和代码来看，核心的误解可能来自Android日志的chatty合并机制，先给你拆解清楚：

1. 日志"chatty"提示是关键 #

你日志里的这一行：

04-29 18:17:53.219 3039 3039 I chatty : uid=0(root) libmemunreachab identical 2 lines

这是Android logcat的优化策略：当短时间内出现完全相同的日志输出时，它会自动合并重复行，用identical N lines来表示有N行重复日志被省略了。

也就是说，你的范围for循环其实完整执行了4次——前1次输出日志，中间2次因为和第一次完全相同被合并，最后1次又输出了日志。实际遍历次数和leak_scc_.size()的数值是一致的，只是日志显示被压缩了。

你可以通过两种方式验证：

• 使用logcat -v raw命令查看日志，这种模式会关闭chatty合并，显示所有原始日志行；
• 修改循环里的日志，加入唯一标识（比如迭代索引）：

  int iter_idx = 0;
  for (auto& it : leak_scc_){
    MEM_ALOGI("leak_scc_ 迭代索引: %d, node references_in_ size: %d.....", iter_idx++, (int)it->node.references_in.size());
  }
  

  这样就能看到每个迭代的索引，确认是否执行了4次。

2. 代码层面的额外排查（如果日志合并不是问题） #

如果验证后发现确实只执行了2次，那再检查这些潜在点：

• 容器的完整性：确认leak_scc_是标准容器（比如std::vector），且在遍历前没有被其他代码意外修改（比如erase操作）；
• 迭代器有效性：虽然你是在所有emplace_back完成后才遍历，但如果leak_scc_是std::vector，多次emplace_back可能触发内存重新分配，但你是在所有插入完成后才遍历，所以迭代器不会失效；
• 自定义容器的遍历逻辑：如果leak_scc_是自定义容器，检查它的begin()和end()方法是否正确返回了覆盖所有元素的迭代范围。

总结 #

大概率是日志被合并导致的视觉误解，通过修改日志输出或者使用raw模式就能确认真实的遍历次数。如果确实存在代码问题，再从容器的完整性和迭代器逻辑入手排查。

内容的提问来源于stack exchange，提问作者shunhui Tang