内存碎片化是 C++ 在高并发服务中的一个关键性能顽疾。碎片分成两类：外部碎片——空闲的内存块零散、不连续，总的空闲内存充足，却无法满足大块内存的分配；内部碎片——分配出去的内存大于实际需求，剩下的空间被闲置。 高并发场景下，高频次的小内存

本文讨论两个需求： 如何让共享库文件也可以直接执行； 如何在可执行文件中用 dlopen 解析自身的函数。 这两个需求汇总起来，可以理解为：如何让一个程序既可以作为共享库，又能够直接运行。这类需求在 Linux 下很常见，ld-linu

1. 引言：为什么我们需要双缓冲？在现代软件开发中，尤其是在高并发、实时性要求极高的系统中，数据的读写分离是一个永恒的话题。最近在处理一个实时数据系统时，我遇到了数据库（MySQL）在高并发读写下的性能瓶颈。传统的加锁机制虽然能保证数据一致

PIC 即 position independent code（位置无关代码），对应编译选项 -fpic：生成适合放入共享库的位置无关代码。 共享库有一个重要特征——可以被多个可执行文件共享，以达到节省磁盘和内存空间的目标。这意味着： 磁

无锁编程（Lock-Free Programming）是现代并发编程中的一种重要技术，它避免了传统的锁机制，如互斥锁（mutex），并通过原子操作确保线程安全。无锁编程能够在多线程环境中显著提高程序的并发性和可伸缩性，减少线程之间的竞争、阻

多线程环境下向数组添加数据的结构时，我们需要考虑线程安全。一般有几种常见的设计方案： 方案 1：互斥锁保护动态数组实现思路：使用互斥锁（std::mutex）保护对数组的每次操作，确保同一时间只有一个线程修改数组。这个方案是最简单最常见的，

库是写好的、可复用的代码。现实中每个程序都要依赖很多底层库，不可能从零开始。本质上库是一种可执行代码的二进制形式，可被操作系统载入内存执行。库有两种：静态库（.a/.lib）和动态库（.so/.dll）——Windows 上是 .lib/.

在 Linux 环境下进行 C++ 编程时，多线程能显著提升程序的并发处理能力，让程序在面对复杂任务时表现得更加高效。但多线程编程并非一帆风顺，死锁问题就像隐藏在暗处的”杀手”，随时可能让程序陷入僵局。 想象一下，你的程序原本运行得好好的，

这是一道关于 Unix fork() 系统调用的经典面试题：每一轮 fork 产生的新进程数量等于当前正在运行的进程数量。题目问——下面这个程序一共输出多少个 -？ #include <stdio.h> #include <sy

一、回顾循环引用问题当两个对象通过 shared_ptr 相互引用时，会产生循环引用问题，导致内存泄漏。因为这两个对象的引用计数永远不会变为 0，即使它们在程序的其他部分已经不被使用了。 典型循环引用： #include <memor

fork 是一个拥有 50 年历史的系统调用，也是一个传奇。一个程序员可以永远不用 read/write，也可以不懂 mmap，但必须懂 fork。fork 没有参数、如此简单，是 UNIX 哲学的布道者们的首选，被写进了几乎每一本操作系统

继传统 UNIX fork 之后，本文介绍 fork 在 Linux 内核中的变体——clone 系统调用的精妙之处。 理解 fork 的原始意义，还是要回到 Melvin Conway 提出 fork 思想的论文 A Multiproce