始终

最近在实际业务中，我遇到了这样一类问题。

首先，我们定义了一个通用类，比如 message Feature。然后，在一个大的特征分组中，我们定义了若干个特征。比如

1
2
3
4
5

message FooGroup {
  Feature foo = 1;
  Feature bar = 2;
  Feature baz = 3;
}

但在实际使用中，我们需要根据配置文件，有筛选地选出其中的某几个来使用——比如选择使用 foo 和 baz。为此，我们会传递 "foo" 和 "baz" 给函数 get_feature，并期待它能返回 const Feature&，分别装着 foo 和 baz 的常量引用。

查阅 Protobuf 的文档之后发现，使用描述器（Descriptor）、字段描述器（FieldDescriptor）和反射（Reflection）来实现该功能。

最近，因为各种原因，我先后两次需要给悠悠在 macOS 上安装钉钉。但是，两次安装钉钉，悠悠都反映通过钉钉和别人语音、视频会议的时候，别人看不见她、听不见她、无法共享屏幕等问题。

归根究底，这都是钉钉在 macOS 上权限控制的问题。

为了分析服务性能瓶颈，今次我们计划用 gperftools 当中的 CPU Profiler 来打印服务当中的性能热点。按官网介绍，以下三种方式之一，可开启 CPU Profiler。

1. 运行时，用 LD_PRELOAD 环境变量加载 CPU Profiler 的共享对象（动态库）。例如 env LD_PRELOAD="/usr/lib/libprofiler.so" /path/to/elf_bin。
2. 链接时，加上 -lprofiler（或者 -ltcmalloc_and_profiler，如果还需要 TCMalloc 的话），而后在运行时通过 env CPUPROFILE=foo.prof /path/to/elf_bin 将性能分析文件写入 foo.prof。
3. 在加上链接参数 -lprofiler 的基础上，在代码内引入头文件 #include <gperftools/profiler.h>，而后在需要分析性能的代码块前后加上 ProfilerStart("/path/to/foo.prof") 及 ProfilerStop()。

这里 (1) 不需要重新编译，但是一看就很山寨；(3) 在分析特定代码片块的性能时很有效，但在意图分析整个程序的性能时就很鸡肋。目光集中在 (2) 上面。

尝试 (2) 时，遇到一个问题。不管如何设置 CPUPROFILE，程序都不会将性能分析文件转储出来。

描述去世之人去世时的阳寿有「得年」、「享年」、「享寿」三种相对文雅的说法。其中

• 得年用于过世之时较年轻之人；
• 享年用于过世之时年龄适中之人；
• 享寿用于过世之时年岁极长之人。

台湾所谓「教育部」之字典的「享寿」词条里提到用法：「習慣上稱卒年六十以上者為『享壽』，不滿六十者稱『享年』，三十以下者稱『得年』。」可为参考。

不过，随着现代人均寿命增加，私以为：卒年四十五以下称得年都不会突兀；卒年七十五以上恐怕称享寿才较为妥帖；若是卒年过百，恐怕得尊称一声「享高寿」了。

很早以前，在学习使用 Python 的 deque 容器时，我实现了一个玩具版的频率限制器。最近需要压测线上服务的性能，又不愿意总是在 QA 那边排队，于是需要自己写一个压测用的客户端。其中一个核心需求就是要实现 QPS 限制。

于是，终究逃不开要在 C++ 中实现一个线程安全的频率限制器。