线程池技术：

当线程数过多时，如果其中大部分线程都处于活动状态，将会导致频繁的上下文切换，从而造成巨大的系统开销。

上下文切换：

什么是线程上下文切换

上下文切换的精确定义可以参考: http://www.linfo.org/context_switch.html。多任务系统往往需要同时执行多道作业。作业数往往大于机器的CPU数，然而一颗CPU同时只能执行一项任务，为了让用户感觉这些任务正在同时进行，操作系统的设计者巧妙地利用了时间片轮转的方式，CPU给每个任务都服务一定的时间，然后把当前任务的状态保存下来，在加载下一任务的状态后，继续服务下一任务。任务的状态保存及再加载，这段过程就叫做上下文切换。时间片轮转的方式使多个任务在同一颗CPU上执行变成了可能，但同时也带来了保存现场和加载现场的直接消耗。(Note. 更精确地说, 上下文切换会带来直接和间接两种因素影响程序性能的消耗. 直接消耗包括: CPU寄存器需要保存和加载, 系统调度器的代码需要执行, TLB实例需要重新加载, CPU 的pipeline需要刷掉; 间接消耗指的是多核的cache之间得共享数据, 间接消耗对于程序的影响要看线程工作区操作数据的大小).

根据上面上下文切换的定义，我们做出下面的假设：

1. 之所以TwoThreadSwitchTester执行速度最慢，因为线程上下文切换的次数最多，时间主要消耗在上下文切换了，两个线程交替计数，每计数一次就要做一次线程切换。
2. “Multi Threads - 100 Threads”比“Multi Threads - 2 Threads”开的线程数量要多，导致线程切换次数也比后者多，执行时间也比后者长。

干活的其实是CPU，而不是线程

再想想原来学过的知识，之前一直以为线程多干活就快，简直是把学过的计算机原理都还给老师了。真正干活的不是线程，而是CPU。线程越多，干活不一定越快。

那么高并发的情况下什么时候适合单线程，什么时候适合多线程呢？

适合单线程的场景：单个线程的工作逻辑简单，而且速度非常快，比如从内存中读取某个值，或者从Hash表根据key获得某个value。Redis和Node.js这类程序都是单线程，适合单个线程简单快速的场景。

适合多线程的场景：单个线程的工作逻辑复杂，等待时间较长或者需要消耗大量系统运算资源，比如需要从多个远程服务获得数据并计算，或者图像处理。

InnoDB使用操作系统线程来处理用户事务请求，它是这样工作的：当InnoDB收到一个用户的请求时，如果已经超过innodb_thread_concurrency预先设置的并发线程数量，那么就会按照innodb_thread_sleep_delay预先设定的值休眠N秒，之后再次尝试连接，重试两次的机制是为了减少CPU上下文切换的次数，以降低CPU消耗。如果请求被接受了，则会获得一个innodb_concurrency_tickets默认500次的通行证，在这些次数用完之前，该线程重新请求时无须再进行前面所说的innodb_thread_concurrency的检查。如果还没有被接受，那么就会进入队列中，直到最终被处理掉。

从MySQL5.5.X版本开始，innodb_thread_concurrency被默认设置为0，表示不限制并发数，表1-2中是该参数的历史默认值。


线程池技术：就是线程复用，多个连接共享线程


binlog group commit技术

在开启binlog的情况下，为了保证主库和从库之间数据的一致性，mariadb/mysq使用了事务的2阶段提交协议，在这种情况下，为了满足数据的持久化需求，一个事务的提交最多会导致3次fsync操作。
为了提高mariadb/mysql在开启binlog的情况下单位时间内的事务提交数，就必须减少每个事务提交过程上导致的fsync的调用次数。binlog gorup commit的基本思想是多个并发提交的事务之间共用一次fsync操作来实现事务对binlog修改的持久化。