场景

Mutex主要用于有大量并发访问并存在cache过期的场合，如

• 首页top 10, 由数据库加载到memcache缓存n分钟
• 微博中名人的content cache, 一旦不存在会大量请求不能命中并加载数据库
• 需要执行多个IO操作生成的数据存在cache中, 比如查询db多次

问题

在大并发的场合，当cache失效时，大量并发同时取不到cache，会同一瞬间去访问db并回设cache，可能会给系统带来潜在的超负荷风险。我们曾经在线上系统出现过类似故障。

解决方法

方法一
在load db之前先add一个mutex key, mutex key add成功之后再去做加载db, 如果add失败则sleep之后重试读取原cache数据。为了防止死锁，mutex key也需要设置过期时间。伪代码如下
(注：下文伪代码仅供了解思路，可能存在bug，欢迎随时指出。)

if (memcache.get(key) == null) {
    // 3 min timeout to avoid mutex holder crash
    if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
        value = db.get(key);
        memcache.set(key, value);
        memcache.delete(key_mutex);
    } else {
        sleep(50);
        retry();
    }
}

方法二
在value内部设置1个超时值(timeout1), timeout1比实际的memcache timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候，马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。伪代码如下

v = memcache.get(key);
if (v == null) {
    if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
        value = db.get(key);
        memcache.set(key, value);
        memcache.delete(key_mutex);
    } else {
        sleep(50);
        retry();
    }
} else {
    if (v.timeout <= now()) {
        if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {
            // extend the timeout for other threads
            v.timeout += 3 * 60 * 1000;
            memcache.set(key, v, KEY_TIMEOUT * 2);

            // load the latest value from db
            v = db.get(key);
            v.timeout = KEY_TIMEOUT;
            memcache.set(key, value, KEY_TIMEOUT * 2);
            memcache.delete(key_mutex);
        } else {
            sleep(50);
            retry();
        }
    }
}

相对于方案一
优点：避免cache失效时刻大量请求获取不到mutex并进行sleep
缺点：代码复杂性增大，因此一般场合用方案一也已经足够。

方案二在Memcached FAQ中也有详细介绍 How to prevent clobbering updates, stampeding requests，并且Brad还介绍了用他另外一个得意的工具 Gearman 来实现单实例设置cache的方法，见 Cache miss stampedes，不过用Gearman来解决就感觉就有点奇技淫巧了。

附：本次Web2.0技术沙龙演讲主题：微博Cache设计谈，需下载请点击演讲稿下menu/download (需登录slideshare)。

• Memcached数据被踢(evictions>0)现象分析
• Web 2.0技术沙龙设想
• Twitter架构图(cache篇)
• FarmVille(美版开心农场)谈架构:所有模块都是一个可降级的服务
• MemcacheDB, Tokyo Tyrant, Redis performance test

if (state == TEXAS) {
        rate = TX_RATE;
        amt = base * TX_RATE;
        calc = 2 * basis(amt) + extra(amt) * 1.05;
} else if ((state == OHIO || (state == MAINE)) {
        rate = ((state == OHIO) ? OH_RATE : ME_RATE);
        amt = base * rate;
        calc = 2 * basis(amt) + extra(amt) * 1.05;
        if (state == OHIO)
                points = 2;
} else {
        rate = 1;
        amt = base;
        calc = 2 * basis(amt) + extra(amt) * 1.05;
}

可能很多人读此代码都有似曾相识之感，不错，我们身边不少程序员就是如此编程的。这段代码就是由于太多Repeat造成罗嗦难懂，结构复杂，维护困难。大家可能都会迅速想到两点重构方法
1. amt, calc 可以移出来
2. 第2个if可以拆分

但是这样就完美了吗？4个if/else是否让人闻到一股不对劲的气味？这段程序是否还是传统结构化编程思维？if条件中state再增多程序会怎样？因此虽然是一段很短的代码，但是重构优化实际是无止境的。

再谈巧合编程(Don’t Programmer by Coincidence)，在很多项目中其实也很常见，巧合编程就是有问题的代码在开发过程中恰好能运行通过，但是运行在别的环境很容易就出问题，比如下面的C++代码

        a = 2;
        b = 3;
        if (a + b != 5) exit(1);

什么情况会exit(1)?

传统智慧认为，项目一旦进入编码阶段，工作主要就是机械的把设计转换成可执行语句。这种态度是许多程序低效、不可维护的最大原因。
⋯
我们大多数人都能够几乎自动地驾驶汽车，我们不用明确的命令我们的脚踩刹车，或是命令手动方向盘，我们只是想“减速并右转”。但是，可靠的司机会不断查看周围的情况，检查潜在的问题，并且让自己在万一发生意外时处在有利的位置上。编码也是这样。

因此开发过程质量问题非常重要, 有经验的程序员懂得如何避开前进过程中的各种雷区。Code review就是在你的驾驶过程中，由另外一名有经验的驾驶员坐在副驾的座位上，帮你纠正各种危险的驾驶习惯，避免在当时或以后踏入各种已知的雷区。

本文读后感已先前在新浪微博发出，收到过几十条转发及评论。微博的内容或许更有灵感并及时，欢迎关注http://t.sina.com.cn/timyang

• 做卓有成效的程序员
• 多服务器通讯层应该如何设计—一次code review小记
• Friendfeed的MySQL key/value存储
• 5%的神话(关于开发效率与职业方向)
• 用Python实现CRUD功能REST服务

1. Test environment

1.1 Hardware/OS

2 Linux boxes in a gigabit ethernet LAN, 1 server and 1 test client
Linux Centos 5.2 64bit
Intel(R) Xeon(R) CPU E5410  @ 2.33GHz (L2 cache: 6M), Quad-Core * 2
8G memory
SCSI disk (standalone disk, no other access)

1.2 Software version

nginx, nginx-0.7.63.tar.gz
Erlang, otp_src_R13B02-1.tar.gz
Java, jdk-6u17-linux-x64.bin, mina-2.0.0-RC1.tar.gz, netty-3.2.0.ALPHA1-dist.tar.bz2
Go, hg clone -r release https://go.googlecode.com/hg/ $GOROOT (Nov 12, 2009)

1.3 Source code and configuration

Linux, run sysctl -p

net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
kernel.panic = 1
net.ipv4.tcp_rmem = 8192	873800	8738000
net.ipv4.tcp_wmem = 4096	655360	6553600
net.ipv4.ip_local_port_range = 1024	65000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

# ulimit -n
150000

C: ngnix hello world module, copy the code ngx_http_hello_module.c from http://timyang.net/web/nginx-module/

in nginx.conf, set “worker_processes  1; worker_connections 10240″ for 1 cpu test, set “worker_processes  4; worker_connections 2048″ for multi-core cpu test. Turn off all access or debug log in nginx.conf, as follows

worker_processes  1;
worker_rlimit_nofile 10240;
events {
    worker_connections  10240;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  0;
    server {
        listen       8080;
        server_name  localhost;
        location / {
            root   html;
            index  index.html index.htm;
        }
          location /hello {
            ngx_hello_module;
            hello 1234;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        }
    }
}

$ taskset -c 1 ./nginx or $ taskset -c 1-7 ./nginx

Erlang hello world server
The source code is available at yufeng’s blog, see http://blog.yufeng.info/archives/105
Just copy the code after “cat ehttpd.erl”, and compile it.

$ erlc ehttpd.erl
$ taskset -c 1 erl +K true +h 99999 +P 99999 -smp enable +S 2:1 -s ehttpd
$ taskset -c 1-7 erl +K true -s ehttpd
We use taskset to limit erlang vm to use only 1 CPU/core or use all CPU cores. The 2nd line is run in single CPU mode, and the 3rd line is run in multi-core CPU mode.

Java source code, save the 2 class as HttpServer.java and HttpProtocolHandler.java, and do necessary import.

public class HttpServer {
    public static void main(String[] args) throws Exception {
        SocketAcceptor acceptor = new NioSocketAcceptor(4);
        acceptor.setReuseAddress( true );

		int port = 8080;
		String hostname = null;
		if (args.length > 1) {
			hostname = args[0];
			port = Integer.parseInt(args[1]);
		}

        // Bind
        acceptor.setHandler(new HttpProtocolHandler());
        if (hostname != null)
        	acceptor.bind(new InetSocketAddress(hostname, port));
        else
        	acceptor.bind(new InetSocketAddress(port));

        System.out.println("Listening on port " + port);
        Thread.currentThread().join();
    }
}

public class HttpProtocolHandler extends IoHandlerAdapter {
    public void sessionCreated(IoSession session) {
        session.getConfig().setIdleTime(IdleStatus.BOTH_IDLE, 10);
        session.setAttribute(SslFilter.USE_NOTIFICATION);
    }

    public void sessionClosed(IoSession session) throws Exception {}
    public void sessionOpened(IoSession session) throws Exception {}
    public void sessionIdle(IoSession session, IdleStatus status) {}
    public void exceptionCaught(IoSession session, Throwable cause) {
        session.close(true);
    }

    static IoBuffer RESULT = null;
	public static String HTTP_200 = "HTTP/1.1 200 OK\r\nContent-Length: 13\r\n\r\n" +
			"hello world\r\n";
	static {
    	RESULT = IoBuffer.allocate(32).setAutoExpand(true);
    	RESULT.put(HTTP_200.getBytes());
    	RESULT.flip();
    }
    public void messageReceived(IoSession session, Object message)
            throws Exception {
        if (message instanceof IoBuffer) {
        	IoBuffer buf = (IoBuffer) message;
        	int c = buf.get();
        	if (c == 'G' || c == 'g') {
        		session.write(RESULT.duplicate());
        	}
        	session.close(false);
        }
    }
}

Nov 24 update Because the above Mina code doesn’t parse HTTP request and handle the necessary HTTP protocol, replaced with org.jboss.netty.example.http.snoop.HttpServer from Netty example, but removed all the string builder code from HttpRequestHandler.messageReceived() and just return a “hello world” result in HttpRequestHandler.writeResponse(). Please read the source code and the Netty documentation for more information.

$ taskset -c 1-7 \
java -server -Xmx1024m -Xms1024m -XX:+UseConcMarkSweepGC -classpath . test.HttpServer 192.168.10.1 8080

We use taskset to limit java only use cpu1-7, and not use cpu0, because we want cpu0 dedicate for system call(Linux use CPU0 for network interruptions).

Go language, source code

package main
import (
   "http";
    "io";
)
func HelloServer(c *http.Conn, req *http.Request) {
    io.WriteString(c, "hello, world!\n");
}
func main() {
     runtime.GOMAXPROCS(8); // 8 cores
     http.Handle("/", http.HandlerFunc(HelloServer));
     err := http.ListenAndServe(":8080", nil);
    if err != nil {
        panic("ListenAndServe: ", err.String())
    }
}

$ 6g httpd2.go
$ 6l httpd2.6
$ taskset -c 1-7 ./6.out

1.4 Performance test client

ApacheBench client, for 30, 100, 1,000, 5,000 concurrent threads
ab -c 30 -n 1000000 http://192.168.10.1:8080/
ab -c 100 -n 1000000 http://192.168.10.1:8080/
1000 thread, 334 from 3 different machine
ab -c 334 -n 334000 http://192.168.10.1:8080/
5000 thread, 1667 from 3 different machine
ab -c 1667 -n 334000 http://192.168.10.1:8080/

2. Test results

2.1 request per second

2.2 latency, 99% requests within(ms)

3. Notes

* On large concurrent connections, C, Erlang, Java no big difference on their performance, results are very close.
* Java runs better on small connections, but the code in this test doesn’t parse the HTTP request header (the MINA code).
* Although Mr. Yu Feng (the Erlang guru in China) mentioned that Erlang performance better on single CPU(prevent context switch), but the result tells that Erlang has big latency(> 1S) under 1,000 or 5,000 connections.
* Go language is very close to Erlang, but still not good under heavy load (5,000 threads)
After redo 1,000 and 5,000 tests on Nov 18
* Nginx module is the winner on 5,000 concurrent requests.
* Although there is improvement space for Go, Go has the same performance from 30-5,000 threads.
* Erlang process is impressive on large concurrent request, still as good as nginx (5,000 threads).

4. Update Log

Nov 12, change nginx.conf work_connections from 1024 to 10240
Nov 13, add runtime.GOMAXPROCS(8); to go’s code, add sysctl -p env
Nov 18, realized that ApacheBench itself is a bottleneck under 1,000 or 5,000 threads, so use 3 clients from 3 different machines to redo all tests of 1,000 and 5,000 concurrent tests.
Nov 24, use Netty with full HTTP implementation to replace Mina 2 for the Java web server. Still very fast and low latency after added HTTP handle code.

• 如何写nginx module
• MemcacheDB, Tokyo Tyrant, Redis performance test
• Thrift, Protocol Buffers installation and Java code howto
• Thrift and Protocol Buffers performance in Java
• Thrift and Protocol Buffers performance in Java Round 2

lighttpd是基于事件驱动的高性能web服务器。mod_cache是在lighttpd上运行的缓存插件。lighttpd+mod_cache 搭建的缓存系统，具有配置简单，性能高，在很多大型系统得到了广泛应用。本次活动由mod_cache作者阙宏宇介绍lighttpd的基础知识，讲解 lighttpd高性能的原理，讨论lighttpd的扩展编写方法等高级话题。也将分享mod_cache插件的特点和使用经验。

在看视频的过程中我在twitter上也分享了阙宏宇的一些观点，同时也引起了一些网友的关注及讨论，部分内容摘录如下(下文每行开头的链接是发言人的twitter ID)

xmpp: 刚看到阙宏宇的lighttpd mod_cache视频，他的调优建议把keep-alive设成=0(相当于关掉)，个人不是很认同

xmpp: 阙宏宇称”使用lighttpd+mod_cache比squid快一个数量级，原因是lighttpd用event/file, squid用thread/db“ 视频第41分钟

xmpp: 阙宏宇最后说web server使用多线程是倒退，并拿memcached单线程跑得很好来证明。但是我觉得并不能单纯这么考虑，一是多核CPU被浪费，二是web server(io密集, 慢连接)和cache server特性有区别不能简单相提并论。

SnaiX: @xmpp 我觉得阙宏宇的言论很有问题，首先所谓的event based也是需要较大消耗的，且，squid有n中模式可以选择，包括了所谓的db based files based。

xmpp: @SnaiX 是阿，他的软件对于某些场景可能有意义，但是大部分情况还是没法代替squid的，视频最后Q&A也看到，比如没法实现合并多个相同资源的并发请求等

xmpp: @eishn: “对于任务的处理, 不可避免会涉及到 multithreading 的问题” 是 @yingfeng 提到的，在我的理解，“任务”是指为了返回请求，需要消耗cpu及io等待,直至输出内容返回网络这个执行过程

yingfeng: @xmpp 读过POSA II便可知道event based只是解决了acceptor端的问题，对于任务的处理，不可避免会涉及到multithreading的问题

xmpp: @SnaiX: 批评多线程者无非就是批评锁，所以1最极端者就用单线程，2退一步者就线程不共享内存，线程间用消息通讯，3普通多线程通常加锁，因此会带来等待锁(其实Semaphore锁对等待线程没什么开销的)及线程切换开销，因此开发多线程程序只要了解底层原理就没什么恐惧的

xmpp: @eishn 你说的是实现方法是协程吗，我倒很想看到你说的实现方法详细描述。如果是协程，它虽然避免了锁，但还是存在切换开销，而且也不能随时切换，我觉得如要利用多核优势，多线程是大势所趋

alpha86: @xmpp 静态文件的请求可以开keep-alive, 动态请求的话其实keep-alive起不到多大效果。

Joshfeng: @xmpp 我个人觉得keep-alive的设置要看服务器上主要是什么类型的文件

xiaoxiaolu: RT @xmpp: … 他的调优建议把keep-alive设成=0(相当于关掉)，个人不是很认同//就web而言,我挺认同的

mikespook: RT: @xiaoxiaolu: RT @xmpp: 刚看到….调优建议把keep-alive设成=0(相当于关掉)，个人不是很认同//就web而言,我挺认同的// 具体情况具体处理，keep-alive 对小文件友好，对高并发不利～

rockyzh: @xmpp 同意，现在已经进入多核时代了，当年的squid以高效的单线程著称，现在可得改改了

TerryTsui: RT: @xmpp: 阙宏宇最后说web server使用多线程是倒退，并拿memcached单线程跑得很好来证明。。。 //memcache 也可以是多线程跑啊

xiaoxiaolu: RT @mikespook: RT: @xiaoxiaolu: RT @xmpp:调优建议把keep-alive设成=0，个人不是很认同//我挺认同// 具体情况具体处理，keep-alive 对小文件友好，对高并发不利～//高并发看情况,若跳出率很高,就关掉,省事的话,一律关掉

SnaiX: @xmpp 在他视频20分钟左右的位置，提到squid和lighty的比较。提到“能不用线程就不用线程，尤其是几个线程在做同一个事情，用这种事件驱动的模型更好“，我不赞同，这种并发的目的就是用来做同一个事情的。其次就是线程模型和事件驱动一点也不冲突。

SnaiX: @xmpp memcached的模型明显是比较简单的模型，为了实现方便而已。所以mc这种东西如果你不适用线程模式或者不对其进行一些特殊优化， 是很难用来吞吐大数据的，因为单线程会使得在write较多数据的时候占用的CPU时间太长，从而直接影响了对别的请求的响应。

tangfl: @SnaiX @xmpp snaix 应该大力推销一下 csf 模式：前端 event driven，中间任务队列调度，后面线程池处理，完美了。。。

eishn: @xmpp 阙宏宇说webserv使用多线程是倒退，基本赞同。不过其mcachd例子不妥，常规evt负载亦不低。然单线程异步io性能甚于多线程，高并发场合由 是，故多线程非最佳。然实现逻辑，多线程是最易用的，故最佳形式是以模拟多线程写逻辑，而以单线程异步实现，这也是我的做法。

jiaojing: RT: @jeffz_cn: rt @xmpp RT: @yingfeng: @xmpp 读过POSA II便可知道event based只是解决了acceptor端的问题，对于任务的处理，…//多线程也只是用来做cpu时间片的分配,协程也是一个不错的选择.切换代价更 小

SnaiX: @xmpp 我认为，如果仅仅是为了避免多线程所造成的程序复杂度上升而在该使用多线程的地方却不使用多线程，是一种无能的表现。譬如说，有言论说：多线程造成你的程序一旦有问题，整个进程就core dump了，所以不稳定。可关键是，你的程序应该有问题么？

SnaiX: RT @tangfl: @SnaiX @xmpp 其实CSF也没什么可高深的，只是我觉得需要有这么一个东西，这样很多东西就可控了。做技术的，不能整天靠凑合来凑合去的过日子。

eishn: @xmpp stackless python 协程可以做到随时切换, 不过不能达到 erlang 那样的协程级别的多核分配, 尽管可以由用户自己非原生实现。协程虽然还是有切换开销, 但是没有无谓切换, 只在类似 io 等待的场合下才会发生切换, 所以切换次数远小于线程。

jiaojing: RT: @eishn: @xmpp stackless python 协程可以做到随时切换, 不过不能达到 erlang 那样的协程级别的多核分配, …。// erlang的smp也是用多线程(一个核一个线程,ps保证)跑多个scheduler.

flierlu: 多线程领域也是在不停发展的，近几年 lock-free 和 wait-free 算法逐渐成熟，加上线程局部内存池等等技术，只要设计上不出大问题，肯定能超越多进程

zhuzhaoyuan: @xmpp: @yingfeng: 读过POSA II便可知道event based只是解决了acceptor端的问题，对于任务的处理，不可避免会涉及到multithreading的问题 || 反对，要看服务类型是IO密集型还是计算密集型的，IO密集型的不需要多线程。

附加说明

• 在Twitter中，@表示reply某人, 类似email中的答复，RT表示retweet,类似email中的转发。
• 从上面看到，Twitter在讨论上处理线索功能上还是比较弱，需要重复RT原文来串联上下文，很需要类似gmail那样conversation的功能。
• 我的twitter ID是xmpp，欢迎大家follow。

• Lua coroutine vs Java wait/notify
• python web.py使用flup lighttpd优化过程
• 搜狐IM
• 了解Linux的进程与线程
• Memcached数据被踢(evictions>0)现象分析

粗略估算又叫费米近似(Fermi problem)，比如坐广州到深圳的和谐号动车组时候就想，广深线每分钟进入火车站人流量有多大？这个似乎要请专业的调查公司才能得到结果，但实际上每个人几乎都可以算出来，尤其是程序员。

1. 和谐号列车有8个车厢，1号和8号是头等车厢，一般坐不满 ，满员估算50人。除去5号餐车。因此共有5×100+100=600个座位。
2. 15分钟一趟，每天从6点到22点，共发车18*(60/15)=72次
3. 根据观察，广深线平时都有座位，但也不会太空。假如平均坐满70%座位的话，每天单向人流量为 72 * 600 * 70% = 30240 人
4. 每分钟人流量为30240/18/60=28人
5. 进一步考虑，需要几个售票窗口。估算平均每个乘客购票需要15秒，则至少7个窗口才不会引起排队现象。这跟平时观察一致，平时非高峰时刻如果窗口在5个以下会出现排长队现象。

72法则

72法则是会计上的一个经验。假设最初投资金额为100元，复息年利率9%(r%)，利用“72法则”，将72除以9（增长率），得8(y)，即需约8年时间，投资金额滚存至200元（两倍于100元），而准确需时为8.0432年。上面的r和y换成任何数字，只要相乘总数是72, 该法则都成立。

72法则在初略估算中经常要用到，比如上面广深线的例子，假如客流月增长率3%, 则24月之后，广深线客流量会翻一番。(24*3=72)

编程领域估算

服务器编程领域经常面临预先估算，因为在程序开发前实际的场景并不存在。据去年《程序员》杂志介绍，奥运订票网站的瘫痪，是因为每秒请求数超过2200次。假如这个请求数都不能预先估算到的话，应该算是架构设计的失败。

更多有趣例子及深入阅读

• 中国共有多少台正在运行中的服务器？
• 你有多少根头发?
• 成年人体的骨头块数。
• 孔子的出生年份（公元）

更多有趣的例子可参看美国马里兰大学更多初略估算测试大全(英文)

• Twitter架构图(cache篇)
• 第一期广州技术沙龙预告
• Facebook平台设计(一)
• 广州技术沙龙设想
• 利用Gearman来实现远程监控与管理

5%的程序员开发效率是其他95%程序员的20倍

(5% of programmers are 20x more productive than the other 95%)

按照80-20法则,80%的程序员几乎不看书,不读Blog,不参加技术会议，不持续学习。这些人也可能会进入大公司，他们日复一日的做着重复的 工作。另外20%则在专业方面比较主动，他们喜欢阅读，喜欢学习，喜欢参加技术活动。这20%当中又会有80%的人可能不会特别成功，他们仍然走在通往成 功的路上奋斗。剩下20%，也就是总数的5%的开发人员具备20倍的开发效率。

那如何成为这5%中的一员呢

Bruce Eckel 的观点：阅读，分析，总结，实践

这5%的人会习惯经常阅读新技术，并喜欢参与各种有潜在价值的新概念的实践，他们会有非常有选择性的参与会议，大部分时间都花在有效率的事情上，将事情做成。

要想比别人效率高出20%，则需要在各个方面达到平衡，而不单只是能将事情搞定那么简单，因此你要使用最好的工具，最优秀的技术，并尽最大的努力。平衡点并 不是从明显的事物上就可以轻松获得，或者是被人告知的经验，或者是大众化的经验。它需要自己摸索并发现事物背后的规律，需要自己去总结并发现。

比如我们通常对各种编程语言优缺点熟记于心，我们通常可以脱口而出比如erlang适合大并发场合等等。但是大部分人不会意识到很多场合语言并不重要。

因此如果你要成为那5你必须持之以恒的坚持学习，多学习编程是有好处的，但是仅仅局限于了解编程是不够的，比如类似以下经验：

• 代码被阅读的时间比写代码的时间要长，如果你的代码不能被人理解，则没人会去改善或者修改其中的bug
• Code review是最有成效的改善软件缺陷的方法，但在我们却经常“没有时间来考虑它”

所以除了精通编程之外，最好多看一些编程方法与协作的书，如并不传授编程技巧的《代码大全》之类的书。

Jeff Atwood (Coding Horror) 的观点：技术博客重要性

当然也有持不同观点者，如Jeff Atwood(coding horror作者)则认为经常分享自己的技术体会比coding更重要，能写的人才能成为那5%。他曾经横穿北美，从美国西岸San Francisco到加拿大的东岸Montreal去给一个大学的学生讲技术Blog的重要性。他在这篇Is Writing More Important than Programming(ppt, 3mb)演讲中提到：

大部分我景仰的程序员都是通过其blog让我景仰，而不是他的代码

……大部分不写blog程序员的理由有：太忙；写了也没人看；没有合适内容可写；觉得自己不善长表达等。

Jeff Atwood大部分观点我是深表赞同的，可喜的是身边乐于分享的越来越多。比如新浪开发者博客今年2月才开张，现在已经有100多篇高质量文章了。

另外我很敬佩的TopLanguage创建者刘未鹏也写过一篇很有名的为什么你应该（从现在开始就）写博客，想必很多朋友都看过。

其他观点

国内曾翻译过Erlang程序设计的Trustno1则认为这5%的人必须是钻研paper的人, 而只是看看rss，热衷于参加各种技术会议，搞搞各种可替代性很强的技术的人是不够格的，他在某帖子中提到：

很简单的两个标准.
标准一,你看到一个问题的第一感觉”这个事情不学3-4年数学算法光靠捣鼓捣鼓API设计模式肯定搞不定”
案例一,老板让你做一个从视频里识别出人脸的程序.
标准二,但凡性能Critial又没有现成方案的东西.
案例二,老板让你做一个实时的全局照明渲染引擎.

原讨论在这里 http://www.javaeye.com/topic/380651 其中一些观点也是有争议的，不过话题已经被锁定不让讨论了;)

总结

想必看了上面这一系列，你对怎样成为那5%已有自己的见解了。你要的答案或许不在这篇文章里，因为Bruce Eckel提到，大部分成为5%的人的经验是只可意会，不可言传的。

• 为什么优秀开发者进入Google后就不参与开源了
• 程序员修炼之道-DRY与巧合编程
• 做卓有成效的程序员
• 2010年技术实践计划
• 中国共有多少台服务器-初略估算初窥

原子操作Atomic

通常操作系统和硬件都提供特性，可以对一个字节进行原子操作的的读写，并且通常在此基础上来实现更高级的锁特性。

• atomic_t结构

原子操作通常针对int或bit类型的数据，但是Linux并不能直接对int进行原子操作，而只能通过atomic_t的数据结构来进行。目前了解到的原因有两个。

一是在老的Linux版本，atomic_t实际只有24位长，低8位用来做锁，如下图所示。这是由于Linux是一个跨平台的实现，可以运行在多种 CPU上，有些类型的CPU比如SPARC并没有原生的atomic指令支持，所以只能在32位int使用8位来做同步锁，避免多个线程同时访问。(最新版SPARC实现已经突破此限制)

另外一个原因是避免atomic_t传递到程序其他地方进行操作修改等。强制使用atomic_t，则避免被不恰当的误用。

atomic_t my_counter = ATOMIC_INIT(0);
val = atomic_read( &my_counter );
atomic_add( 1, &my_counter );
atomic_inc( &my_counter );
atomic_sub( 1, &my_counter );
atomic_dec( &my_counter );

• 原子操作硬件上的实现

Solaris的实现是基于test-and-set的指令，并且该指令为原子操作。比如Solaris的实现在SPARC上是基于ldstub和cas指令，在x86上用的是cmpxchg指令。但是Linux似乎直接用的add指令。

OpenSolaris i386的实现

	movl	4(%esp), %edx	/ %edx = target address
	movl	(%edx), %eax	/ %eax = old value
1:
	leal	1(%eax), %ecx	/ %ecx = new value
	lock
	cmpxchgl %ecx, (%edx)	/ try to stick it in
	jne	1b
	movl	%ecx, %eax	/ return new value
	ret

在Linux源代码asm_i386/atomic.h中

/**
 * atomic_add - add integer to atomic variable
 * @i: integer value to add
 * @v: pointer of type atomic_t
 *
 * Atomically adds @i to @v.  Note that the guaranteed useful range
 * of an atomic_t is only 24 bits.
 */
static __inline__ void atomic_add(int i, atomic_t *v)
{
        __asm__ __volatile__(
                LOCK "addl %1,%0"
                :"=m" (v->counter)
                :"ir" (i), "m" (v->counter));
}

锁的类型

• Spinlocks自旋锁

如果锁被占用，尝试获取锁的线程进入busy-wait状态，即CPU不停的循环检查锁是否可用。自旋锁适合占用锁非常短的场合，避免等待锁的线程sleep而带来的CPU两个context switch的开销。

• Semaphores信号量

如果锁被占用，尝试获取锁的线程进入sleep状态，CPU切换到别的线程。当锁释放之后，系统会自动唤醒sleep的线程。信号量适合对锁占用较长时间的场合。

• Adaptive locks自适应锁

顾名思义，自适应锁就是上面两种的结合。当线程尝试申请锁，会自动根据拥有锁的线程繁忙或sleep来选择是busy wait还是sleep。这种锁只有Solaris内核提供，Linux上未见有相关描述。

几种锁的性能比较(Windows操作系统下，第一种类似atomic_inc, 2,3类似spinlock, 4,5类似semaphore)

(图片来源：Intel Software Network)

Java synchronization

再理论联系实际一下，看Java中的锁底层如何实现的。这篇关于JVM的Thin Lock, Fat Lock, SPIN Lock与Tasuki Lock中讲到Java synchronization实际上也是一种自适应锁。

于是，JVM早期版本的做法是，如果T1, T2，T3，T4…产生线程竞争，则T1通过CAS获得锁(此时是Thin Lock方式)，如果T1在CAS期间获得锁，则T2，T3进入SPIN状态直到T1释放锁；而第二个获得锁的线程，比如T2，会将锁升级（Inflation）为Fat Lock，于是，以后尝试获得锁的线程都使用Mutex方式获得锁。

Java AtomicInteger的实现，似乎和Solaris的实现非常类似，也是一个busy wait的方式

   /**
     * Atomically increments by one the current value.
     *
     * @return the updated value
     */
    public final int incrementAndGet() {
        for (;;) {
            int current = get();
            int next = current + 1;
            if (compareAndSet(current, next))
                return next;
        }
    }

    /**
     * Atomically sets the value to the given updated value
     * if the current value {@code ==} the expected value.
     *
     * @param expect the expected value
     * @param update the new value
     * @return true if successful. False return indicates that
     * the actual value was not equal to the expected value.
     */
    public final boolean compareAndSet(int expect, int update) {
        // unsafe.compareAndSwapInt是用本地代码实现
        return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
    }

Solaris

感觉OpenSolaris在很多地方要比Linux优秀，Solaris在理论设计和实践上都非常优雅，而Linux内核很多地方似乎更偏工程实践方向一些。另外Solaris用来做学习操作系统更合适，它的mdb几乎无所不能。

我在VirtualBox虚拟机上安装了OpenSolaris，非常容易安装，使用这个Minimal OpenSolaris Appliance OVF image for VirtualBox 2.2 简易方法，安装一个没有gui的版本，大约3分钟以内就可以装好。OpenSolaris安装软件和Ubuntu一样方便，使用 pkg install SUNWxxx 的命令，比如 pkg install SUNWcurl

• 了解Linux的进程与线程
• 谈Linux内核定时器
• Lua coroutine 不一样的多线程编程思路
• Lua coroutine vs Java wait/notify
• 如何写nginx module

Thrift Loop    : 10,000,000
Get object     : 14,394msec
Serdes thrift  : 37,671msec
Objs per second: 265,456
Total bytes    : 1,130,000,000

ProtoBuf Loop  : 10,000,000
Get object     : 8,170msec
Serdes protobuf: 33,054msec
Objs per second: 302,535
Total bytes    : 829,997,866

From the result, Protocol Buffers is 1.1 times faster than Thrift!

And from the Google Protocol Buffers group, why the optimize for speed was not turn on by default.

When using C++ or Java protocol buffers, for best performance you need to add a line to your .proto files:

option optimize_for = SPEED;

Otherwise, by default, the compiler optimizes for code size.  Optimizing for code size results in generated code that around a half to a third of the size, but runs an order of magnitude slower…

Here is the original post

• Thrift and Protocol Buffers performance in Java
• Thrift, Protocol Buffers installation and Java code howto
• MemcacheDB, Tokyo Tyrant, Redis performance test
• C, Erlang, Java and Go Web Server performance test
• 利用Gearman来实现远程监控与管理

The test is very similiar as the Python test. the .proto and .thrift file are copied from the above python test.

The .thrift content:

struct dns_record {
1: string key,
2: string value,
3: string type = 'A',
4: i32 ttl = 86400,
5: string first,
6: string last
}

typedef list<dns_record> biglist

struct dns_response {
1: biglist records
}

service PassiveDns {
biglist search_question(1:string q);
biglist search_answer(1:string q);
}

The .proto content

package passive_dns;

message DnsRecord {
required string key = 1;
required string value = 2;
required string first = 3;
required string last = 4;
optional string type = 5 [default = "A"];
optional int32  ttl = 6 [default = 86400];
}

message DnsResponse {
repeated DnsRecord records = 1;
}

From the document, I learn that the optional and default values are one of the benefits of both serialization libraries. A record that matches the default value does not need to be included in the serialized output.

I wrote up a simple test program to compare thrift, protocol buffers. I tested the serialize and deserialize together, because this is the most called part in most scenarioes.

Test 1: 10,000,000 times

ProtoBuf Loop  : 10,000,000
Get object     : 15,130msec
Serdes protobuf: 68,600msec
Objs per second: 145,772
Total bytes    : 829,996,683

Thrift Loop    : 10,000,000
Get object     : 12,651msec
Serdes thrift  : 36,904msec
Objs per second: 270,973
Total bytes    : 1,130,000,000

Test 2: 1,000,000 times

ProtoBuf Loop  : 1,000,000
Get object     : 1,094msec
Serdes protobuf: 7,467msec
Objs per second: 133,922
Total bytes    : 83,000,419

Thrift Loop    : 1,000,000
Get object     : 524msec
Serdes thrift  : 5,969msec
Objs per second: 167,532
Total bytes    : 113,000,000

The serde_* functions are the times needed to serialize, and de-serialize the java object to and from a byte[].

The result in Java was that Protocol Buffers 1.2-2 times slower than Thrift. (in the python test was 4~10 times). And PB binary size is smaller than Thrift. I think this is acceptable, and Google may improve the Protocol Buffers performance in the future version.

Download my test code in Java: thrift-protocol-buffers-java.tgz,

More information about thrift and protocol buffers: Thrift, Protocol Buffers installation and Java code howto

Update: There is another Thrift vs. Protocol Buffers compare non-performance factors.

UPDATE 2 (Apr 17): There is a performance tuning parameter optimize_for = SPEED (thanks Steve Chu) for Protocol Buffers, please see my next performance tests Thrift and Protocol Buffers performance in Java Round 2

• Thrift and Protocol Buffers performance in Java Round 2
• Thrift, Protocol Buffers installation and Java code howto
• MemcacheDB, Tokyo Tyrant, Redis performance test
• C, Erlang, Java and Go Web Server performance test
• 利用Gearman来实现远程监控与管理

1. build and install thrift

install boost
cd <boost_root>/tools/jam
./build_dist.sh
# linux* will depends the platform
cp stage/bin.linux*/bjam <boost_root>
# build boost, use bjam will faster
cd <boost_root>
./configure –without-icu –prefix=/usr/local/boost
./bjam -toolset=gcc –build-type=release install –prefix=/usr/local/boost

# build thrift
./bootstrap.sh
./configure –with-boost=/usr/local
make
make install

2. Build Thrift java library

install apache ant if necessary

cd lib/java/
ant

get libthrift.jar

3. Create .thrift file and gen Java code

(See http://wiki.apache.org/thrift/Tutorial for more .thrift tutorial info)
tim.thrift

struct dns_record {
1: string key,
2: string value,
3: string type = 'A',
4: i32 ttl = 86400,
5: string first,
6: string last
}

service TestDns {
dns_record test(1:string q);
}

<thrift_root>/bin/thrift –gen java tim.thrift
code will be generated in gen-java/*.java

4. Write java code

// new object
dns_record dr = new dns_record(key, value, type, ttl, first, last)
// serialize
TSerializer serializer = new TSerializer(new TBinaryProtocol.Factory());
TDeserializer deserializer = new TDeserializer(new TBinaryProtocol.Factory());
byte[] bytes = serializer.serialize(dr);

see also: http://wiki.apache.org/thrift/ThriftUsageJava

II. Protocol Buffers install and Java code

1. Build and install Protocol buffers

./configure
make
make install

2. Build protobuf Java library

install maven if not necessary

cd protobuf/java
mvn test
mvn package

get jar from target/protobuf-java-x.x.x.jar

3. Create .proto file and gen Java code

tim.proto

package dns;

message DnsRecord {
required string key = 1;
required string value = 2;
required string first = 3;
required string last = 4;
optional string type = 5 [default = "A"];
optional int32  ttl = 6 [default = 86400];
}

message DnsResponse {
repeated DnsRecord records = 1;
}

bin/protoc –java_out . tim.proto

4. Write Java code

// protocol buffer need a builder to create object
Dns.DnsRecord.Builder b = Dns.DnsRecord.newBuilder();
b.setKey("key");
b.setValue("value...");
...
b.builder();

byte[] bytes = dr.toByteArray();
Dns.DnsRecord dr2 = Dns.DnsRecord.parseFrom(bytes);

III. Resources

Thrift: http://incubator.apache.org/thrift/

Protocol Buffers: http://code.google.com/apis/protocolbuffers/

Tim’s Blog: http://timyang.net/

• Thrift and Protocol Buffers performance in Java
• Thrift and Protocol Buffers performance in Java Round 2
• MemcacheDB, Tokyo Tyrant, Redis performance test
• C, Erlang, Java and Go Web Server performance test
• 利用Gearman来实现远程监控与管理