关键字解释

• 条件变量： 线程中的条件变量是等待共享数据内的某个条件出现，不是等待的互斥锁！条件变量特别适用于多个线程等待某个条件的发生。
• auto与std::function： 在实际使用中都用 auto 关键字来代替std::function… 这一长串了
  std::function<void(const Foo&, int)> f_add_display = &Foo::print_add;
• EPOLLIN：TCP连接的远端主动关闭连接，也是可读事件；EPOLLOUT：主动建立连接，发起非阻塞的 TCP连接(connect也可以这么判断)，连接建立成功的事件也是可写事件。
• hpp： 其实质就是将.cpp的实现代码混入.h头文件当中，定义与实现都包含在同一文件，则该类的调用者只需要include该hpp文件即可，无需再将cpp加入到project中进行编译。而实现代码将直接编译到调用者的obj文件中，不再生成单独的obj，采用hpp将大幅度减少调用project中的cpp文件数与编译次数，也不用再发布烦人的lib与dll，因此非常适合用来编写公用的开源库。
• Polkit：polkit 是一个应用程序级别的工具集，通过定义和审核权限规则，实现不同优先级进程间的通讯：控制决策集中在统一的框架之中，决定低优先级进程是否有权访问高优先级进程。Polkit 在系统层级进行权限控制，提供了一个低优先级进程和高优先级进程进行通讯的系统。和 sudo 等程序不同，Polkit 并没有赋予进程完全的 root 权限，而是通过一个集中的策略系统进行更精细的授权。Polkit 定义出一系列操作，例如运行 GParted, 并将用户按照群组或用户名进行划分，例如 wheel 群组用户。 网页链接 了解linux 权限， 然后定义每个操作是否可以由某些用户执行，执行操作前是否需要一些额外的确认，例如通过输入密码确认用户是不是属于某个群组。通过下面几个常用的操作类型，可以了解 polkit 到底能做什么：
  1）、systemd-logind (org.freedesktop.login1.policy) 定义用户是否有权限进行关机、重启、挂起、休眠等操作，即使有其它用户登录时， polkit 也能管控某个用户的上述权限。
  2）、udisks (org.freedesktop.udisks2.policy) 定义文件系统挂载、加密磁盘打开等操作。
  3）、NetworkManager (org.freedesktop.NetworkManager.policy) 定义网络打开和关闭， wifi 和移动网络间的切换。

---

• 桩（stub）代码: 是指用来代替关联代码或者未实现代码的代码。如果函数B用B1来代替，那么，B称为原函数，B1称为桩函数。打桩就是编写或生成桩代码。打桩的目的主要有：隔离、补齐、控制。
  隔离是指将测试任务从产品项目中分离出来，使之能够独立编译、链接，并独立运行。隔离的基本方法就是打桩，将测试任务之外的，并且与测试任务相关的代码，用桩来代替，从而实现分离测试任务。例如函数A调用了函数B，函数B又调用了函数C和D，如果函数B用桩来代替，函数A就可以完全割断与函数C和D的关系。
  补齐是指用桩来代替未实现的代码，例如，函数A调用了函数B，而函数B由其他程序员编写，且未实现，那么，可以用桩来代替函数B，使函数A能够运行并测试。补齐在并行开发中很常用。控制是指在测试时，人为设定相关代码的行为，使之符合测试需求。
• xml: 配置文件中相对路径的问题，如果可执行程序和配置文件不在同一个目录下的时候，当连接的配置文件中使用的相对路径，则要注意是否填写的是相对于配置文件的路径还是相对于执行命令的路径。
• stub: 为屏蔽客户调用远程主机上的对象，必须提供某种方式来模拟本地对象，这种本地对象称为存根(stub)，存根负责接收本地方法调用，并将它们委派给各自的具体实现对象。每个远程对象都包含一个代理对象stub，当运行在本地Java虚拟机上的程序调用运行在远程Java虚拟机上的对象方法时，它首先在本地创建该对象的代理对象stub, 然后调用代理对象上匹配的方法，代理对象会作如下工作：与远程对象所在的虚拟机建立连接 、包(marshal)参数并发送到远程虚拟机 、等待执行结果 、解包(unmarshal)返回值或返回的错误 、返回调用结果给调用程序 。stub 对象负责调用参数和返回值的流化(serialization)、打包解包，以及网络层的通讯过程。
• BAK : Backup (File Name Extension) 备份文件扩展名
• multimap: multimap的begin()~end()是默认排好序的，按key的大小规则有序输出。map的排序默认按照key从小到大进行排序。C++ STL中标准关联容器set, multiset, map, multimap内部采用的就是一种非常高效的平衡检索二叉树，map内部本身就是按序存储的（比如红黑树）。在我们插入<key, value>键值对时，就会按照key的大小顺序进行存储。这也是作为key的类型必须能够进行<运算比较的原因
• EPOLLIN：TCP连接的远端主动关闭连接，也是可读事件；EPOLLOUT：主动建立连接，发起非阻塞的 TCP连接(connect也可以这么判断)，连接建立成功的事件也是可写事件。
• 指针函数：函数的返回值为一个指针。类型说明符* 函数名（参数）： int * f(x);
• 函数指针：

 int  f(int x){return x};     //函数定义
 
 int (*f)(int x);
 
 using f=int(*)(int);
 
 typedef int f (int);          //f为一个函数名
 
 typedef int （*f ） (int);    //f为一个函数名
 
 typedef decltype（p）*  f;    //f为一个函数指针

 f或&f    //都可以当做函数指针

 decltype（p）*

• j<<1并不改变j本身的值。

• 中间件：中间件是在操作系统功能范围外为应用提供服务的多用途软件。任何位于内核和用户应用之间的软件都可以是中间件。中间件不提供传统应用的功能，而是将软件与其他软件衔接。由于中间件能够让数据从一个应用流动到另一个中，中间件就是程序中可织入的，可重用的，与业务逻辑无关的各种组件。中间件(middleware)是基础软件的一大类，属于可复用软件的范畴。顾名思义，中间件处于操作系统软件与用户的应用软件的中间。中间件在操作系统、网络和数据库之上， 应用软件的下层，总的作用是为处于自己上层的应用软件提供运行与开发的环境，帮助用户灵活、高效地开发和集成复杂的应用软件。在众多关于中间件的定义中，比较普遍被接受的是 IDC 表述的：中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信。分类：数据访问中间件，远程调用中间件，消息中间件，交易中间件，对象中间件。常见的中间件的技术：企业级分布式应用服务EDAS、消息队列MQ、Kafka、RPC等等。

• 虚拟主机： 虚拟主机可以共享资源，共享同一的IP，利用虚拟主机把若干个带有单独域名的站点建置在一台服务器上，不必再为建立一个站点而购置单独的服务器和用巨资申请专线作为网络信息出口。一台服务器上的不同虚拟主机是各自独立的，并由用户自行管理。但一台服务器主机只能够支持一定数量的虚拟主机，当超过这个数量时，用户将会感到性能急剧下降。虚拟主机技术是互联网服务器采用的节省服务器硬件成本的技术，虚拟主机技术主要应用HTTP（Hypertext Transfer Protocol，超文本传输协议）服务，将一台服务器的某项或者全部服务内容逻辑划分为多个服务单位，对外表现为多个服务器，但是用的是统一的对外ip,利用http请求头的host字段进行区分是哪台虚拟主机。从而充分利用服务器硬件资源。

• 中台： 参考链接
  1.中台由来及兴起原因：最早源于芬兰游戏公司Supercel的快速决策，快速研发，快速把产品推向市场，而游戏引擎、服务器等后台基础则不需要过度关注。后面由阿里在国内引进这种模式，阿里提出建设整合阿里产品技术和数据能力的强大中台，组建“大中台，小前台”的组织和业务体制。兴起原因：避免大量的重复建设和资源浪费，减少重复造轮子。搭建中台系统完美解决重复造轮子问题。

2. 阿里中台：在业务的不断催化滋养下，将自己的技术和业务能力沉淀出一套综合能力平台，具备了对于前台业务变化及创新的快速响应能力。阿里分为6类：业务中台（提供重用服务）、数据中台（数据分析能力）、算法中台（提供算法能力）、技术中台（提供自建系统部分的技术支撑能力）、 研发中台（提供自建系统部分的管理和技术实践支撑能力）、组织中台（资源调度）。
3. 数据中台：中台就是公共服务平台，数据中台就是将数据加工以后封装成一个公共的数据产品或服务，提供数据分析能力，帮助从数据中学习改进，调整方向。数据产品往往不是直接提供给用户使用的，而是提供给业务应用使用的。

• 冒烟测试： 冒烟测试其实是微软首先提出来的一个概念，和微软一直提倡的每日build（构建版本）有很密切的联系。具体说，冒烟测试就是在每日build（构建版本）建立后，对系统的基本功能进行简单的测试。这种测试强调程序的主要功能进行的验证，而不会对具体功能进行更深入的测试。冒烟测试可以理解为是版本转测试之前，对系统的基本功能进行简单的测试。冒烟测试特点：
  (1)这种测试强调程序的主要功能进行的验证，而不会对具体功能进行更深入的测试。
  (2)冒烟测试是随着版本转测进行的，它应该是一个开关(判断版本能否转测试)而不是一个研发流程中的测试阶段。
  (3)冒烟测试用例一般选取的是测试用例中level 0的用例，保证主功能可用。