东风草堂博客

网络IO主流程

TNonblockingServer使用的网络io模型为非阻塞同步io模型，accept由单个io线程处理，recv由多个io线程处理，相应的rpc事务处理由另外的线程池完成，处理完成后通知对应的io线程将处理结果进行send。

accept连接

所有网络连接由ioThreads_[0]线程监听端口，在listenHandler中处理，accept后生成一个clientConnection，如果存在多个io线程，ioThreads_[0]线程通过robin算法从所有ioThreads_中选择一个io线程处理事务，即ioThreads_[0]通过pipe管道将clientConnection信息通知被选择的io线程，被选择的io线程此时会收到通知并处理notifyHandler，被选择的io线程在notifyHandler中将clientConnection信息读取出来，再进行recv数据并解析处理。

recv接收

golang使用起来总体感觉比较方便，里面很多思想都是相同的，学习过c/c++的朋友就很容易理解，封装继承多态都差不多，对异常处理有一些不一样，和java比较类似。

两种nlogn时间复杂度的排序算法，一个归并排序，一个快速排序。归并排序和快速排序都采用了分治的思想来解决排序的问题，将大问题转化为小问题进行处理，归并排序是由下到上，先划分子问题到不能再划分的地步，再进行合并操作，而快速排序是先分区排序，将分区点放在最终排好序的位置，然后对分区点两边的子数组再进行分区排序处理，所以快排是由上到下进行处理的。归并排序和原始数组的有序程度无关，时间复杂度都是nlogn，但是空间复杂度为O(n)，而快速排序大部分情况下的时间复杂度可以做到nlogn，但也有极端情况退化为n^2，另外归并排序是稳定的排序算法，但快排不是，只是快排可以原地排序，空间复杂度为O(1)，所以实际使用过程中，还是快排用的比较广泛。

冒泡排序、插入排序和选择排序介绍，各有什么优缺点，这三个排序算法最坏时间复杂度都达到了n^2，根据排序效率，是否稳定排序等方面来考虑，优先选择插入排序。

使用微信小程序反编译技术来获取任意小程序的前端源码，本篇文章旨在如何学习别人的优秀技术。

使用docker容器技术快速搭建wordpress站点，适合有一定程序经验的人操作，使用docker技术方便后续快速迁移。

栈在表达式求值中的应用

实际上，编译器就是通过两个栈来实现的。其中一个保存操作数的栈，另一个是保存运算符的栈。我们从左向右遍历表达式，当遇到数字，我们就直接压入操作数栈；当遇到运算符，就与运算符栈的栈顶元素进行比较。

如果比运算符栈顶元素的优先级高，就将当前运算符压入栈；如果比运算符栈顶元素的优先级低或者相同，从运算符栈中取栈顶运算符，从操作数栈的栈顶取 2 个操作数，然后进行计算，再把计算完的结果压入操作数栈，继续比较。

栈在括号匹配中的应用

什么是完美转发？网上资料很多，简单总结一下，就是通过函数参数传递给函数里面的另外一个函数时，参数的属性不能变化，原来是左值的还得是左值，原来是右值的还得是右值。

左值比较简单，默认就是，关键是这右值，当一个右值当作参数传递给另外一个函数时，这个右值便有了自己的名字，于是变成了左值，这才是问题所在。

1
2
3
4
5
6
7

funtion(左值) {
    forward(左值)
}

funtion(右值) {
    forward(右值)
}

我们要让它进入转发的目标函数参数时也是右值才行，这里需要用到特殊引用和std::forward来解决问题，另外需要了解什么是引用折叠。

异常处理

就一个连接池而已，为什么要采用装饰者模式，听着咋感觉那么高深？

所谓连接池，也就是连接先不close，放入池中，等待下次需要用的时候，直接从池中取出即可用，省去了tcp握手的时间，所以这个可以看作是一个长连接，知道连接池清除空闲连接把多余的连接清除掉才会释放。

而普通的连接，用完后如果生命周期内不再使用了，就会销毁掉。

所以基于普通的连接，要定义出线程池的那种用完放回线程池的连接，就需要把close的方法进行重写，所以可以采用继承的方法实现，相当于产生了两个子类，一个是普通连接类，一个是线程池化的连接类。

这个设计模式的功能就是实现订阅与发布的功能，一旦有消息更新，即可将最新的消息同步给所有的订阅者，无需订阅者主动来询问，如果订阅者无需这些消息了，只需要取消订阅即可，后续有新的消息就不会再次打扰。

适用于对于相同的数据需要表现为不同的行为的功能，比如，得知爸爸要回来了，儿子就会立马停止玩游戏，妈妈立马开始准备晚餐。也有可能是很多人都想订阅这些数据，比如求职者先将要找工作的需求交给猎头，猎头那里有很多这样的需求，一旦有公司有需求，猎头那里就会立马通知所有的要找这份工作的求职者，让他们分别去面试，公司选择优秀的人才入职。

生活中有很多类似的场景，都可以用观察者模式来解释，所以设计模式的灵感也来源于生活。另外一方面，也实现了逻辑与应用的分离，从上面的例子也可以看出，底层数据只有一份，但是可以用在几个不同的场景，如果新的场景，也就相当于多了一个订阅者而已。

基于模板实现的观察者模式

网上面有很多实现了的观察者模式，用的都是普通类，但由于模型应用场景，比如订阅的消息类型各式各样，有string、int或者自定义class，那就需要改用模板类了。