面试贴——哔哩哔哩C++二面

同学，我想问下一面是海面么？

问题6的gpt4的回答（个人认为在前一题是单例模式的前提下，这一题应该结合local static来回答会更好） 在C++中，类的static成员变量在程序启动时分配内存，即在进入main函数之前，此时会完成所有静态存储期变量的初始化。这些静态成员变量的内存分配发生在程序的数据段中 — 特别是，如果它们有初始化值则位于初始化数据段（data段），如果它们未被显式初始化则位于未初始化数据段（BSS段），这两都是程序内存布局的一部分。 在C++11中引入了local static变量的线程安全初始化的特性。Local static变量是定义在函数内部的静态存储期变量，它们也位于程序的数据段中，但它们的初始化是懒惰的（延迟的）。它们不是在程序启动时初始化，而是在包含它们的函数第一次执行到local static变量声明的地方时初始化。在多线程环境下，C++11保证了这种初始化操作的线程安全性。 为了理解local static变量的线程安全初始化如何实现的，我们可以依据编译器转换后的代码示例来看。例如，使用cppinsights等工具可以查看到编译器将如下C++代码： int counter() { static int count = 0; return ++count; } 转换为底层的线程安全的实现，实际上会有类似下面的伪代码： #include <mutex> int counter() { static std::mutex count_mutex; static int count; static bool count_initialized = false; if (!count_initialized) { std::lock_guard<std::mutex> lock(count_mutex); if (!count_initialized) { count = 0; count_initialized = true; } } return ++count; } 在实际的实现中，编译器通常会采用更加优化的同步机制，来保证在不同线程中第一次执行到static变量的声明时，仅有一个线程会进行初始化，而其他线程将会等待初始化完成。需要注意的是，这种线程安全的初始化行为通常是通过静态本地变量特有的机制来完成的，而不是通过用户代码中可见的互斥量(mutexes)。在多数现代编译器中，这种同步机制是隐含的，不需要程序员显式编写线程同步代码。 总而言之，在C++11及以上版本，考虑到Linux内存布局，类的static成员变量在数据段内存分配，local static变量也在数据段中分配，并且在函数内部首次声明点进行线程安全的懒初始化。这种线程安全保障是由编译器提供的，一般通过原子操作或低层次同步原语来实现，而不是通过程序员手动编写的同步代码。</std::mutex></mutex>

不是咋我都还在筛简历啊

佬投的是什么岗位？

面试的是什么岗位

简历初筛一万年😭😭😭

请问楼主二面后有后续吗？

请问楼主base地是上海嘛？

打电话问了，说在横向对比中，hr说可以看一看其他机会，这是不是g了😅

诶我B站cpp为啥还没过筛

想问一下static成员变量是什么时候分配内存的啊，是在编译阶段还是初始化的时候，网上搜出来都有，有点懵

当你尝试在只有2GB物理内存的系统中使用malloc分配4GB内存时，实际结果取决于系统的虚拟内存和交换空间（swap space）配置。以下是可能发生的情况： 1. 虚拟内存允许：在大多数现代操作系统中，虚拟内存机制允许分配的内存量超过物理内存。这意味着操作系统将使用硬盘作为“交换空间”来补充物理内存。当物理RAM不足以容纳所有当前活跃的内存页面时，操作系统会将一些不常用的数据移动到交换空间，释放物理内存供其他程序使用。 2. 内存过载（Overcommitment）和OOM Killer：Linux系统默认允许内存过载，即允许分配的总虚拟内存量超过物理内存加上交换空间的总和。系统认为不会所有分配的内存都会被实际使用。但如果所有程序都试图使用其分配的内存，将触发OOM（Out-Of-Memory）Killer，由系统决定杀掉一些进程以释放内存。 3. malloc返回NULL：如果系统的虚拟内存加上交换空间还是不足以分配4GB内存，malloc将无法分配内存并返回NULL。这是告诉你的程序无法分配所需的内存空间。 从Linux系统调用的角度来看malloc过程： - malloc调用：当你在程序中调用malloc时，库函数最初可能不会立即从操作系统请求内存。C库通常有一个内存池来优化小块内存的分配效率。如果请求的内存超过了某个阈值（例如，使用mmap的阈值），malloc就会调用内核。 - brk和mmap系统调用：对于较大的内存请求，malloc通常使用mmap（文件映射）系统调用来映射匿名页面，这不增加传统的程序数据段的大小。对于较小的请求，malloc可能使用brk系统调用来扩展或减少进程的数据段（heap）。 在使用mmap时，操作系统会创建一个虚拟地址空间，实际的物理内存分配可能会推迟到程序访问这些地址时才发生，这是按需分页（demand paging）的一个特点。即使malloc返回了一个有效的指针，也不意味着等同于物理内存已经被分配，真正的分配发生在虚拟页首次被访问时，此时如果物理内存不足，操作系统会从交换空间映射或换出一页内存。 总结一下，如果在只有2GB物理内存的系统中请求malloc分配4GB内存，操作系统和C库将使用虚拟内存机制来尝试满足请求。成功与否取决于系统的交换空间大小和OVERCOMMIT的设置。在内存实际耗尽之前，很可能malloc成功，但进程在实际使用内存时可能会变得非常缓慢，因为操作系统需要频繁地进行页面交换。如果内存使用超出了可用的虚拟内存和物理内存的总和，可能导致内存分配失败或系统启动OOM Killer。 来自gpt4的简单回答