几年前我开始使用vi/vim来支持日常的程序开发工作，使用的原因非常简单，一是因为当时所有的开发和线上都是linux，对于vi的原生支持和轻巧非常有吸引力，二是vi的全键盘操作非常的快捷，熟练之后旁人肯定会觉得酷酷的。而我今年突然对emacs萌生兴趣的原因其实更简单：装逼！vi被称为编辑器之神，而emacs则是神之编辑器，从使用神器的人晋升为神，这是多么高端大气上档次。于是，我怀着各种粗俗卑鄙低劣的想法脑中还不禁浮现几天后我摆出emacs老手的姿态语重心长地对vier说“我年轻的时候也是这么独爱vi“ 边啧啧自笑边开始学习起了emacs。

    内核中最初勾引我好奇心的还是内存管理方面，我们平时编写应用程序时，一个进程所能拥有的内存大小几乎可以趋近于物理内存最大值或是超越这个值，虽然知道内核做内存方面的映射或是swap然后向我们的用户空间呈现出所谓的虚拟内存，但还是对其中实现疑惑甚多，一些关于内存的名词也是有许多，什么虚拟地址，内核线性地址，内核逻辑地址，balablabla...

    一个程序员解决问题的能力，如果粗略来分，会有哪些等级？

    一般我们可以通过工具vmstat, dstat, pidstat来观察CS的切换情况。vmstat, dstat只能观察整个系统的切换情况，而pidstat可以更精确地观察某个进程的上下文切换情况。这里我用了chaos库中task_service的一个测试用例来说明情况(chaos库是我写得一个高性能并发网络库，而task_service是一个提供了多线程通信的异步消息队列)。

    在上家公司曾写过这样一个服务，用户通过我的应用（以下简称fri_svr）索取自己的好友信息，而fri_svr需要向第三方平台（如：人人，Facebook）通过http协议批量请求用户数据，由于用户数据可能很大（几k几十k的级别），所以整个req/rep的过程通常会很慢，平均大概会在 1s - 10s 之间，这样当瞬时请求量到一定级别后，就会造成fri_svr的内存暴涨且响应不了前端的请求，原因在于fri_svr会对前端的每个请求hash到（根据user_id）专门用于http请求的线程队列中（也即是one thread per queue模型），当前端向fri_svr的请求速率大于平台响应fri_svr的，那么就会造成fri_svr中队列的积攒，内存的暴涨，且无法在超时时间内响应前端请求。

    对于服务器的优化，很多人都有自己的经验和见解，但就我观察，有两点常常会被人忽视 - 环境切换 和 Cache Line同步 问题，人们往往都会习惯性地把视线集中在尽力减少内存拷贝，减少IO次数这样的问题上，不可否认它们一样重要，但一个高性能服务器需要更细致地去考察这些问题，这个问题我将分成两篇文章来写： 1）从一些我们常用的用户空间函数，到linux内核代码的跟踪，来看一个环境切换是如何产生的 2）从实际数据来看它对我们程序的影响

    上周有位网友联系我说chaos在他的环境上编译不过，并发给我了一些错误信息 查看了编译错误信息之后并没得到太多排查的入口，询问了对方的编译器版本是gcc 4.6.3，而我基本都是工作在4.1版本左右的gcc上，周末在家自己搭了个4.6.3的环境，果然也出现了同样的问题，之后发现这是因为高版本gcc(g++)对c++模板的检查更为严格所导致的，我们直接看例子

    alarm函数是信号方式的延迟，这种方式不直观，这里不说了。 仅通过函数原型中时间参数类型，可以猜测sleep可以精确到秒级，usleep/select可以精确到微妙级，nanosleep和pselect可以精确到纳秒级。 而实际实现中，linux上的nanosleep和alarm相同，都是基于内核时钟机制实现，受linux内核时钟实现的影响，并不能达到纳秒级的精度，man nanosleep也可以看到这个说明，man里给出的精度是：Linux/i386上是10 ms ，Linux/Alpha上是1ms

    前阵子接触到一道关于数组内部链表(多用于内存池技术)的数据结构的题, 这种数据结构能够比普通链表在cache中更容易命中, 理由很简单, 就是因为其在地址上是连续的(=.=!), 借这个机会, 就对cpu cache进行了一个研究, 今天做一个简单的分享, 首先先来普及一下cpu cache的知识, 这里的cache是指cpu的高速缓存. 在我们程序员看来, 缓存是一个透明部件. 因此, 程序员通常无法直接干预对缓存的操作. 但是, 确实可以根据缓存的特点对程序代码实施特定优化, 从而更好地利用高速缓存.