为何引入<iostream>会改变C++程序的program break表现？

头文件会不会直接改变program break？ #

不会，但引入<iostream>会间接影响它的表现——因为<iostream>会触发C++标准库的全局初始化逻辑，在你自己的代码运行前就提前调用malloc分配了一些内部资源（比如IO流的缓冲区、全局对象的内存），这会把program break提前抬高到某个阈值。后续你自己调用malloc时，直接从标准库预分配的内存池里取，不会再调整program break，所以三次打印的地址完全一致。

为什么会出现这些差异？ #

C和C++的malloc/free行为不一样 #

• 用gcc编译成C程序时，glibc的malloc在释放堆顶的大内存块后，会检查是否能把内存还给操作系统，满足条件就会调用sbrk()降低program break，所以能回到初始值。
• 而C里的operator new/delete虽然底层依赖glibc，但C标准库会维护自己的内存池，释放后的内存会被放回内存池留着复用，不会立刻还给操作系统，所以program break不会回落。

的初始化提前占了堆空间 #

当你引入<iostream>，程序启动时就会初始化std::cout、std::cin这些全局对象，这个过程会提前malloc内存。此时堆的program break已经被抬高，内存池也初始化好了。你后续的malloc请求直接从内存池拿，不会触发brk()调整，所以三次打印的地址没变化。

要是不引入<iostream>，你的代码是第一个触发malloc的，此时内存池还没建，malloc直接向操作系统申请内存（抬高program break），free后因为C++的内存池策略，内存留着复用，所以program break保持高位。

怎么验证这个逻辑？ #

你可以在代码开头手动加一行void* tmp = malloc(1); free(tmp);，模拟<iostream>的初始化效果，再跑测试代码，会发现program break的变化和引入<iostream>时完全一致。

内容的提问来源于stack exchange，提问作者Mikayel Smbatyan