C++后端面试八股文

一、C++ 语言基础与底层原理

请解释 new / delete 和 malloc / free 的区别和联系，以及使用它们时需要注意什么

new 和 delete 是C++的运算符（Operator）。这意味着它们可以被类（通过 operator new 和 operator delete）甚至全局作用域重载，从而提供自定义的内存管理行为

malloc 和 free 是C标准库提供的库函数（Function）。它们不能被重载。

new：在分配内存后，会自动调用对象的构造函数来初始化这块内存。它会根据提供的类型自动计算所需的内存大小。

delete：在释放内存前，会自动调用对象的析构函数来清理对象拥有的资源（如文件句柄、其他动态内存、锁等）。

malloc：仅仅分配指定字节数的原始、未初始化的内存块。它需要程序员手动计算所需内存大小（通常使用 sizeof），并且对其分配的内存没有任何类型信息或构造行为。

free：仅仅释放由 malloc (或 calloc, realloc) 分配的内存。它对这块内存上的任何对象（如果有）没有任何析构行为。

new：成功时返回指向已构造好的对象的类型化指针（例如 MyClass*）。如果分配失败，在标准行为下抛出 std::bad_alloc 异常（而非返回 nullptr）。

malloc：成功时返回 void* 类型指针，程序员必须手动将其强制转换（cast）为所需类型。如果分配失败，返回 NULL

简述 C++ 的内存分区（栈、堆、全局/静态存储区、常量存储区、代码区）以及对象在这些区域的创建过程。

栈区：自动分配/释放（函数调用时创建，返回时销毁）

堆区：手动分配/释放

全局/静态存储区：程序启动时分配，程序结束时释放

常量存储区：只读内存,生命周期与程序相同

代码区：只读内存

移动语义 (std::move) 和完美转发 (std::forward) 解决了什么问题？它们的实现原理（引用折叠）是什么？在什么情况下使用？(RValue Reference, Universal Reference)

移动语义：允许资源所有权转移（而非复制），显著提升资源管理效率

完美转发：模板函数参数转发时丢失值类别（左值/右值）和 CV 属性

保持参数的原始值类别（左值/右值）和类型属性（const/volatile）

面向对象：

详细解释 C++ 中的虚函数机制（vptr, vtable）。

虚函数表：编译器为每个包含虚函数的类生成的静态函数指针数组

vptr：编译器自动添加到每个对象实例中的隐藏指针

多重继承下菱形继承（钻石问题）是如何产生的？C++ 如何通过虚继承来解决它？（涉及 virtual base class pointer, vtordisp 等，至少讲清概念和原理）

A
/ \
B C
\ /
D

数据冗余（存储开销）:
- B 的实例包含它自己的成员变量以及从 A 继承来的成员变量（我们称之为 A_base）。
- 同样，C 的实例也包含自己的成员变量和另一个 A_base。
- 当 D 继承 B 和 C 时，它会把 B 和 C 的完整实例都包含进来，这意味着 D 的实例中包含了两个独立的 A_base 子对象！
- 如果 A 中有很大的成员变量，或者有很多个 D 实例，这种冗余会造成显著的内存浪费。
成员访问二义性（Ambiguity）:
- 假设类 A 中有一个成员函数 void func()。
- 现在，你创建一个 D 的对象 dObj 并调用 dObj.func()。
- 编译器迷茫了！它发现这个 func() 可以通过两条路径找到：
  - 路径一：D -> B -> A::func()
  - 路径二：D -> C -> A::func()
- 编译器无法确定你想调用通过 B 继承来的 A::func() 还是通过 C 继承来的 A::func()（尽管它们是同一个函数）。
- 结果：编译器报错——对成员 'func' 的访问不明确。

A
/ \
(virtual) (virtual)
B C
\ /
D

使用虚继承

class A { /* ... */ }; // Base class

class B : public virtual A { /* ... */ }; // Virtual inheritance from A
class C : public virtual A { /* ... */ }; // Virtual inheritance from A

class D : public B, public C { /* ... */ }; // Regular multiple inheritance

虚继承如何解决菱形继承问题：

消除数据冗余：
- 虚继承引入了一个机制：在 D 的对象中，所有虚继承自 A 的路径共享一个单一的 A 子对象实例。
- 无论你经过 B 还是经过 C，最终访问的都是同一个 A_base。
- D 的对象布局不再是 B 包含一个 A、C 包含一个 A，而是 B 和 C 部分中包含虚基类指针（vptr） 或 偏移量（offset），它们指向最终派生类 D 构造函数创建的那个唯一共享的 A 子对象。D 会直接包含这个共享的 A 子对象。这避免了存储两份 A 的数据。
消除成员访问二义性：
- 既然整个 D 对象中只有一个 A 子对象实例，那么 A 的所有成员（数据成员和成员函数）在 D 中也自然只有一份。
- 当在 D 的对象上调用 func() 时，编译器可以无歧义地找到这个唯一的 A::func()，路径唯一确定。不会再出现调用哪个 A 的 func() 的困惑。

面向对象的三大特性（封装、继承、多态）在 C++ 中是如何体现的？

核心机制：通过class关键字定义类，用private/protected/public控制访问权限

类型支持：

公有继承（class Derived : public Base）→ "是一个"关系
保护继承（protected）→ 限制基类公有成员
私有继承（private）→ 实现继承（C++特有）

实现基础：虚函数表（vtable）+ 动态绑定

并发与同步：

解 std::thread, std::mutex, std::lock_guard, std::unique_lock, std::condition_variable 的用法和区别。

thread：用于创建和管理新的执行线程，代表一个执行单元

包含以下成员函数

join()：阻塞调用函数，通常为主线程，等待*this线程执行结束

detach()：分离*this线程，与thread对象解耦，允许其在后台允许

get_id（）获取线程标识符

mutex：提供基本的独占互斥所有权语义，防止多个线程访问共享数据，避免数据竞争

lock():尝试获取互斥锁，如果互-互斥锁已经被其它线程持有，则阻塞

unlock():释放互斥锁

try_lock():尝试获取互斥锁，如果锁不可用立即返回

lock_guard:自动管理mutex的锁定和解锁：构造时自动lock关联的互斥量，析构时自动unlock

unique_lock：相较于lock_guard更将灵活，且增加了更多的特性

支持延迟上锁

支持尝试锁定

支持多次锁定和解锁

支持条件变量：condition_variable

可移动但不可复制

下面给出unique_lock使用的一个示例

condition_variable：条件变量，用于在多个线程间的同步操作，一个线程可以阻塞等待某个条件成立，其他线程可以在条件可能发生变化时通知等待的线程

wait(std::unique_lock<mutex>& lock, Predicate pred)，当后面条件不成立阻塞

notice_one()唤醒一个正在wait的线程

notice_all()唤醒全部wait的线程

std::mutex mtx;
std::condition_variable cv;
bool data_ready = false;// 生产者线程
void producer() {{std::unique_lock<std::mutex> lock(mtx); // 上锁// ...生产数据...data_ready = true;} // unique_lock 这里可能解锁，更晚些也行cv.notify_one(); // 通知消费者
}// 消费者线程
void consumer() {std::unique_lock<std::mutex> lock(mtx); // 构造时上锁// 关键：wait 会在内部原子地解锁 mtx 并使线程阻塞等待通知// 收到通知后（可能虚假唤醒），wait 会重新尝试获取锁cv.wait(lock, []{ return data_ready; }); // 直到 data_ready 为真// 此时 lock 持有锁，数据安全可用// ...消费数据...data_ready = false;
} // 解锁

std::atomic 解决了什么问题？它相比直接使用锁的优势和局限在哪里？

解决了无锁或低锁并发编程中的核心问题，安全，高效的在多线程环境下访问和修改共享数据，而无需每次都使用重量级别的互斥锁

相较于直接使用锁：高频轻量操作，无阻塞操作，更少的缓存行竞争

局限于：使用场所有限，存在ABA问题，而且由于较弱的内存序可能会导致非原子变量的读写操作被CPU重新排序到错误的位置，破坏程序逻辑

简述无锁编程（Lock-Free）的思想以及 CAS 操作。无锁队列的基本实现思路？

无锁编程是一种并发编程范式，其核心目标是设计在多线程环境下无需使用传统互斥锁（如 std::mutex）也能正确、高效地访问共享数据结构的算法。

无锁算法的关键特征是：即使某些线程被任意延迟（如被操作系统挂起、发生页错误），也至少有一个线程能够取得进展（完成操作）。

乐观并发控制

依赖硬件原子指令

提高并发性和可伸缩性

CAS思想伪代码描述如下

bool compare_and_swap(T* ptr, T expected, T new_value) {
if (*ptr == expected) { // 比较内存当前值是否等于预期值
*ptr = new_value; // 如果相等，则用新值替换
return true; // 操作成功
}
return false; // 操作失败（值已被其他线程修改）
}

无锁队列

struct Node {
T data; // 存储的数据
std::atomic<Node*> next; // 指向下一个节点的原子指针
};

class LockFreeQueue {
private:
std::atomic<Node*> head; // 指向队列头节点（哨兵节点或真实头）
std::atomic<Node*> tail; // 指向队列尾节点
};

二、操作系统与网络

操作系统原理：

Linux 进程间通信（IPC）有哪些主要方式？对比它们的优缺点和适用场景。

管道：最简单的IPC形式，在具有亲缘关系（通常是父子或兄弟） 的进程间创建单工（半双工）字节流通道。数据写入管道的写入端，从读取端顺序读取（FIFO）。

命名管道：突破管道必须具有亲缘关系的限制，允许任何进程（甚至无亲缘关系） 通过打开这个“文件”名进行通信。遵循FIFO原则。

消息队列：在内核中维护的消息链表。进程可以向队列添加结构化的消息（有类型和负载数据）或从队列中读取特定类型的消息。消息具有优先级（POSIX）或类型（SysV）。

共享内存：速度最快的IPC方式！内核将同一块物理内存映射到多个进程各自的用户空间地址范围。进程可以直接读写这块内存，就像访问自己的内存一样，无需内核介入拷贝。

信号量：它是一个用于同步多个进程（或线程）对共享资源（如共享内存区域、文件、硬件设备）访问的计数器。基本操作是PV操作（wait/P - 申请资源减小计数，signal/V - 释放资源增加计数）。

socket：最强大、最通用的IPC/RPC机制。支持不同主机（网络IPC）或同一主机（Unix Domain Socket）上进程间通信。

Linux 中文件描述符（File Descriptor）的本质是什么？select/poll/epoll I/O 多路复用的区别和各自的优势？epoll 的水平触发（LT）和边沿触发（ET）模式区别？

Linux中的文件描述符不是文件本身，也不是指向文件内容的指针，其为一个非负整数，代表一个进程级别打开文件表的条目索引，每个进程都存在一个打开文件表，当进程打开一个文件的时候，内核会在这个表中创建一个条目，这个表中存在指向系统级别打开文件表的指针，文件的访问模式等，同时存在一个系统打开文件表，每个条目代表一个真正被打开的文件实例，时间上，这个文件描述符就是已打开IO资源的句柄

select：存在数量限制：1024 || 这里叙述一下这个的流程，调用select，内核扫描用户传入fd_set中的所有fd，检查它们的状态，随后当有fd超时或者就绪，标记，全部标记完返回，用户再次扫描

poll：长度可变化，事件分离

epoll：内核使用红黑树组织列表，使用双向链表管理就绪列表，内核使用回调极值仅在fd状态发生变化的时候将其加入就绪列表，返回值只拷贝就绪的事件信息，使用一个单独的函数添加修改删除内核需要剪视的fd，使得每次不需要传入所有需要监视的fd，监视列表在内核中维护

水平触发：只要fd缓冲区处于就绪状态，就会持续报告这个事件

边缘触发：只在fd缓冲区状态发生改变的时候，才会进行报告

用户态和内核态切换的开销在哪里？

首先介绍一下用户态和内核态

用户态：应用程序运行的环境，CPU在这个状态指向的指令受限，不能访问特权硬件资源

内核态：操作系统内核运行的环境，CPU在这个状态下拥有最高权限

开销主要来源于以下几个方面

硬件上下文保存和恢复==（通用寄存器，指令指针，栈指针，状态寄存器）

CPU流水线，缓存以及分支预测失效==流水线刷新，TLB失效，Cache污染（内核代码将热点数据挤出缓存），分支预测干扰

进程的虚拟地址空间布局是怎样的？

现代操作系统为每个进程提供一个私有的，连续的，独立的虚拟地址空间

一般从高地址到低地址部分为

内核空间操作系统内核的代码、数据和每个进程的内核栈（处理系统调用/中断）、页表等关键数据结构。注意，所有进程共享同一份内核空间映射

用户栈

内存映射区将文件内容映射到进程地址空间。这是 mmap 系统调用的主要应用

用户堆

未初始化数据段 .bss 存储全局/静态变量

已初始化数据段 .data 显式初始化的全局变量和静态变量

代码段 .text

网络协议：

详细描述一次完整的 HTTP 请求过程（从输入 URL 到浏览器显示，涉及 DNS、TCP 握手、HTTP 请求/响应、TLS 握手等）。

阶段0：

用户输入URL

浏览器解析URL，提取关键信息，包括协议，主机名，端口号，未指定使用默认端口，路径等等

检查缓存，浏览器检查内置HSTS，没有，进入下一步

阶段1：

本地缓存未命中

操作系统进行DNS查询，操作系统查询本地的DNS缓存，没有

将DNS请求发送配置的DNS递归解析器，如果其本地还没有

迭代查询：顺次查询根域名服务器，顶级域名服务器，权威域名服务器，得到对应IP地址

返回给操作系统，缓存

阶段2：建立传输连接-TCP握手

阶段3：如果使用的时https协议：进行TLS握手，流程写在了下面

阶段4：客户端构造HTTP请求，发送给服务端，服务端收到，并返回

阶段5：浏览器渲染

TLS握手流程：

1.TLS 第一次握手：客户端向服务器发起加密通信请求，发送 ClientHello 消息。

客户端主要发送以下信息：

支持的 TLS 协议版本，如 TLS 1.2。
客户端生成的随机数（Client Random），用于生成「会话密钥」的一部分。
客户端支持的密码套件列表，如 RSA 加密算法。

2.TLS 第二次握手：服务器收到客户端请求后，向客户端发送 ServerHello 消息作为响应。

服务器回应的内容包括：

确认的 TLS 协议版本，如果浏览器不支持，则关闭加密通信。
服务器生成的随机数（Server Random），用于生成「会话密钥」的一部分。
确认的密码套件列表，如 RSA 加密算法。
服务器的数字证书（Certificate）。

3.TLS 第三次握手：客户端收到服务器的响应后，首先通过 CA 公钥确认服务器的数字证书的真实性。

如果证书验证通过，客户端从数字证书中取出服务器的公钥，并用该公钥加密报文，向服务器发送以下信息：

一个随机数（pre-master key），该随机数将被服务器的私钥解密。
加密通信算法改变通知，表示随后的信息都将使用「会话密钥」加密通信。
客户端握手结束通知，表示客户端的握手阶段已经结束。

4.TLS 第四次握手：服务器收到客户端的第三次握手消息后，通过协商的加密算法，计算出本次通信的「会话密钥」。

然后，服务器向客户端发送以下信息：

加密通信算法改变通知，表示随后的信息都将使用「会话密钥」加密通信。
服务器握手结束通知，表示服务器的握手阶段已经结束。
客户端和服务器的握手阶段全部结束，建立安全连接，可以开始进行加密通信。

TLS1.3改进了上述行为

首先是直接发送客户端公钥

然后服务端恢复证书签名和自己的公钥

这样双方就都持有各自的公钥可以进行加密了

TCP 和 UDP 的核心区别是什么？TCP 如何保证可靠传输（序列号、确认应答、超时重传、流量控制、拥塞控制）？

面向连接和无连接

可靠性和尽力而为

TCP传递字节流，UDP传递消息/数据报

TCP有流量控制，拥塞控制，超时重传，确认应答，序列号等复杂机制，UDP没有

解释 TCP 的三次握手和四次挥手过程，为什么是三次不是两次？为什么挥手需要四次？TIME_WAIT 状态的作用是什么？

对于为什么是三次握手：

两次握手情况下：我们假设这样一种场景，由于网络阻塞，客户端发送的一个请求连接没有到达，客户端发送了第二个连接请求，此时第一个请求到达，服务器返回，并且认为自己同客户端建立了连接，但是这个回复到达客户端的时候，由于客户端已经发送了新的连接就会丢弃，然后如果第二个请求到达，服务器以为这个是新的连接，就再次返回，此时客户端收到后建立连接，但是这样就造成服务端多了一个连接，所以我们采用三次握手，如果客户端丢弃了这个回复，那么服务端就会因为超时释放那个连接

同时第三次握手使得服务端知道客户端同步了自己的序号

对于为什么是四次挥手：这个理由就很多了

全双工需要双向独立关闭

被动关闭方需要处理遗留数据

主动关闭方需要确认对方的 FIN主动关闭方需要确认对方的 FIN

TIME-WAIT 状态的作用

可靠地终止最后一个 ACK：确保被动关闭方能够成功收到第四次挥手的ACK

消除旧连接报文干扰：使得此时网络中属于这个连接的报文全部过期