二八原则源自经济学理论，表述为：通常一个企业80%的利润来自于20%的项目。由此推广出对日常生活的很多描述，如20%的人投资明天，80%的人消费于今天；20%人的正面思考，80%的人负面思考等。20%和80%只是一个概数，表示少数与绝大多数的对比，它的主要思想是不要平均、对等地看待和处理问题，而是认真分析并找到问题的关键点，集中精力于这些关键点上，获得事半功倍的效果。

二八原则也适用于软件领域，通常的表述：计算机在80%的时间执行20%的常用代码或是系统在80%的时间使用着20%的常用数据。只是简单描述不会产生感性认识，下面来看几个例子。

计算机体系中的存储结构，见下图：

数据通常存储于计算机的外部设备上，但每个数据的处理都得经过CPU。正常情况下CPU可以操作的数据只是所有数据的一部分，为了减少经常通过外接总线取数据的时间消耗，就有了内部存储器的诞生。同样的道理，CPU与主存之间尽管有高速总线连接，但无奈处理频率不一样，取常用数据的时候CPU还是会等待很长时间，这样就有了CPU内部寄存器，用于缓存CPU常用的数据。（注：计算机的存储体系是最初设计时就定义好的，这里为了描述方便，还原它的设计过程）。注意到这里很多时候提到的一个词：常用。正常情况下我们会经常操作数据中很常用的那部分，所以基于这种概率的缓存策略是很有用的。

Java因执行速度慢饱受诟病，后来JVM中引入的JIT(Just-in-Time)编译器用于将常用的Java字节码编译为机器码保存起来，下次执行时就不用再去解释这些字节码，这样可以有效提高Java的执行速度。同样，在分析Java对象的生存周期后，就可以对那些大量产生，但有效期很短的对象快速执行GC。JVM的内存分代和GC模型充分考虑到对象生存周期及大小的问题，以正确对待客观现实的方式解决JVM内存使用的问题。

还有一个值得探讨的问题是乐观锁与悲观锁。正常情况下，我们只会操作表中的少数数据行，这时如果为了数据一致性而锁住整个表，就会大大降低DB性能。这种行为可以说成在80%时间只是操作部分行，少数20%的时间才会有对整个表的操作。客观的做法是降低锁的粒度，以更符合实际情况的行为来操作锁。尽管可能增加解决锁冲突的复杂度，但对DB性能的提高是可观的。这种DB锁的问题也出现在程序中，如Hashtable，就可以用ConcurrentHashMap提高并发性能。

在列举了一些实际问题后发现，很多时候对于事实数据的分析是在程序或是系统出现问题以后才做的，这样的问题如性能瓶颈，响应时间等。在分析清楚事实数据的本身属性及系统的症结之后，就可以有针对性的提出解决方案，用于解决极少数关键问题对整个系统的影响。同样在设计阶段，如果能认识到系统中的主要问题，就可以针对性地设计以提前避免瓶颈的出现。

怎样找到系统的关键点，决定于事实数据的属性，系统的关键指标，设计者的经验等。如果在设计之初不能很清楚地找到关键点，就应该采取保守策略，不做任何想法优化，等出现问题时再去处理。这样的好处是如果为了解决所认为的关键问题而引入复杂的逻辑，倒是降低了系统的开发和维护成本。

其实在软件流程上的很多时间，找关键点的目的就是为了优化，提高系统可用性。优化应当以事实数据或是分析报告为切入点，在不确定关键点的时候不能想当然地做优化。以JavaEye前段时间很热的一个帖子http://www.javaeye.com/topic/680130来说。如此优化的前提，应当是在分析完大量数据请求后，明确这几个状态码的请求占绝大多数，那么这样的优化才是成功的。

二八原则可以有很多解读，但主要一点就是找准主要矛盾。每个人可以试着分析自己系统或是模块的关键点，花更多心思来维护，以获得更优的结果。