循环引用是学习智能指针过程中的一个小难点，笔者愚钝，明明知道是两个指针互相引用导致了内存泄漏，但看各种文字资料时，脑子里总是一团浆糊，感觉似懂非懂，于是自己绘制了几张图片，思路和概念才清晰起来，希望这篇博客能帮助有同样困惑的同学解惑。 shared_ptr 的实现要明白循环引用，我们首先需要知道shared_ptr是如何实现的，它内部包含两个指针，一个指向我们要管理的资源对象，另一个指向则指向

Zlib是一个广泛使用的开源数据压缩库，稳定高效。它的核心是Deflate算法，是一种结合Lz77算法和哈夫曼编码的高效压缩算法。 Lz77算法让我们想象这样一个字符串 1ABCDEFGWWABCDEFGABCDEFG 其中ABCDEFG重复了3次，一共23个字符，如果采用UTF-8编码，每个字母占据1字节，这个字符串共占据23字节。如果我们想要压缩这个字符串，利用字符串中的重复信息进行压缩无疑是

笔者在学到template函数时，兴致勃勃地写了一个强大的模板函数，遵循着良好的编程习惯，将它的声明放在 .h 文件中，将实现放在 .cpp 文件里。然后，在编译的时候没有任何问题，却在链接时报错 “undefined reference”。百思不得其解下，费了半天功夫才查找资料填了这个坑。 问题就出在编译器编译的步骤上。 模板的实现首先需要明确的是，在编译的过程中，编译器是如何处理模板的，也就是

std::string_view是C++17引入的新特性，它不持有内存，无法修改它指向的字符串,也不保证其所指向的字符串是空字符结尾的（因为 string_view 可以观察一个 std::string 的中间部分）。string_view包含一个指向字符串对象的指针和对应的长度。 常用方法 除了append()和push_back等会修改字符串内容的方法，std::string_view拥有大部

C++ 中的可变参数模板 (Variadic Templates)是 C++11 引入的最重要和最强大的特性之一，是泛型编程的基石。它允许我们创建可以接受任意数量、任意类型参数的函数模板或类模板。它以一种完全类型安全、在编译期展开的方式，解决了传统 C 语言中可变参数（如 printf）的类型安全问题。 可变参数模板之前的可变参数编程在 C++11 引入可变参数模板之前，如果我们想实现一个接受可变

在C++17之前，C++并没有跨平台的统一文件操作解决方案，不同的平台需要依赖不同的API或者第三方库来处理文件操作。C++17引入的std::filesystem就解决了这个痛点。 常见函数以下按与你之前相似的格式，列出并详解 <filesystem> 中日常最常见的函数及其关键点： fs::exists(p) 判断路径 p 是否存在（文件、目录或符号链接）。 返回true 或

引言std::thread对象在创建完成时，对应的线程就会开始异步执行，但是如果我们想要得知线程的执行结果，那么就需要手动设计和实现一套同步机制。为此C++引入std::future，提供了一个访问异步操作结果的机制。 1#include <future> std::future是一个“未来值”的代理，我们并不直接创建它，而是通过头文件<future>中的其他手段来获取

忙等待与阻塞等待互斥锁能够解决竞态条件的问题，但是它本不提供任何关于事件通知的机制。如果我们想利用mutex::try_unlock（或者另设一个全局标志位）+sleep()+死循环的忙等待(busy-waiting)方式，把是否能够解锁这一信息作为线程之间通信的机制，那么这种方式是相当低效的。 忙等待的线程会占用CPU核心来执行毫无意义的重复检查，消耗大量的资源，妨碍其他线程的任务调度 如果为

同步与互斥同步调用指的是调用的对象在被调用后会阻塞调用方直到被调用方执行完成，而线程天然是异步调用的。但是不同线程的任务片段之间可能会存在严格的先后顺序，例如线程1负责任务A和C，线程2负责任务B，3个任务必须严格按照A->B->C的顺序执行，那么我们就需要在线程1执行任务A的时候阻塞线程2，任务A完成后解除线程2的阻塞并阻塞线程1直到任务B完成。这样维护和协调线程任务片段之间先后顺序

1. 进程与线程 进程是cpu资源分配的最小单位，线程是cpu调度的最小单位 我们可以将程序定义为对资源进行计算的过程。在早期的计算机中并没有线程的概念，进程就是最基本的运行单位，它在拥有资源所有权，负责对资源进行隔离的同时，也执行计算任务。这是因为早期的CPU只有一个物理核心，也没有逻辑核心和超线程的概念，在物理上只能同时执行一个计算任务。但是随着计算机技术的发展，CPU的核心数越来越多，单核