性能遭遇可伸缩性 多线程

记住一句名言：出来混总是要还的。

我们设计一个系统希望用户用起非常的爽快，这操作界面多友好，这响应速度多快，这多么安全和稳定，目标达到了，钱也赚了，用户量越来越大，我们发现系统处理不了了，怎么办？

 

系统的性能度量按照科学的角度是需要用工具认真测试的，它有很多个切面来衡量，性能度量有两个大的方面：第一个是有多块，第二个是有多少？所以关注系统的性能我们要仔细度量，我们到底是要求速度呢？还是说工作量，但是所有这一切在用户眼中是浮云，他们只关心：操作友好吗？速度够快吗？安全可用和稳定吗？我们人多了你还能抗得住吗？

 

一个机器的性能是有限的，我们应该投资我们的架构可以跑在多个机器上，这样我们才能够达到用户的那个需求：我们人多了你要抗得住。一个程序如果在单机上运行得非常好但是未必在多个机器上运行得好。

 

性能和伸缩性有时候是对立的，但是伸缩性又非常重要，所以我们应该做这个选择题：伸缩性 > 性能。程序的设计理念应该是：正确和安全，然后考虑跑得更快，程序如果只追求快速，那么可能会带来复杂性和低维护性，比如破坏OO的封装，使用了难以看懂的算法，代码优化在系统总体性能优化上占的比重很低，我们应该把中心放在设计上和整个体系的把握，避免不成熟的代码优化。

 

现在说说多线程：

多线程可以提高性能，同时还提供可伸缩性，好了，要在性能和可伸缩性这个矛盾对立的两个关注点上使用好线程不是很简单的，线程带来了协调开销（比如加锁，信号，内存同步），上下文切换，生命周期管理，调度等等开销，如果使用不当，多线程程序将比顺序化程序还慢。在Java的多线程编程中，锁是必然遇到的，锁带来了串行化和性能开销，系统中如果减少锁的竞争可以提高伸缩性和性能，所以我们要尽量减少锁被持有的时间，锁被请求的频率，或者用协调机制取代独占锁从而允许更好的并发性。