CDN
CDN的全称是Content Delivery Network，即内容分发网络(图片来自百度百科) 。CDN常用于大的素材下发，比如图片和视频，你在淘宝上打开一个图片，这个图片其实会就近从CDN机房拉去数据，而不是到阿里的机房拉数据，可以减少阿里机房的出口带宽占用，也可以减少用户加载素材的等待时间。
CDN在互联网中被大规模使用，像视频、直播网站，电商网站，甚至是12306都在使用，这种设计对公司可以节省带宽成本，对用户可以减少素材加载时间，提升用户体验。看到这，有没有发现，CDN的逻辑和Memcache的使用很类似，你可以直接当他是一个互联网版的cache优化。
Java JIT
JIT全称是Just-in-time Compiler，中文名为即时编译器，是一种Java运行时的优化。Java的运行方式和C++不太一样，因为为了实现write once, run anywhere的跨平台需求，Java实现了一套字节码机制，所有的平台都可以执行同样的字节码，执行时有该平台的JVM将字节码实时翻译成该平台的机器码再执行。问题在于字节码每次执行都要翻译一次，会很耗时。
图片来自郑雨迪Introduction to Graal ，Java 7引入了tiered compilation的概念，综合了C1的高启动性能及C2的高峰值性能。这两个JIT compiler以及interpreter将HotSpot的执行方式划分为五个级别：
level 0：interpreter解释执行
level 1：C1编译，无profiling
level 2：C1编译，仅方法及循环back-edge执行次数的profiling
level 3：C1编译，除level 2中的profiling外还包括branch（针对分支跳转字节码）及receiver type（针对成员方法调用或类检测，如checkcast，instnaceof，aastore字节码）的profiling
level 4：C2编译
通常情况下，一个方法先被解释执行（level 0），然后被C1编译（level 3），再然后被得到profile数据的C2编译（level 4）。如果编译对象非常简单，虚拟机认为通过C1编译或通过C2编译并无区别，便会直接由C1编译且不插入profiling代码（level 1）。在C1忙碌的情况下，interpreter会触发profiling，而后方法会直接被C2编译；在C2忙碌的情况下，方法则会先由C1编译并保持较少的profiling（level 2），以获取较高的执行效率（与3级相比高30%）。
这里将少部分字节码实时编译成机器码的方式，可以提升java的运行效率。可能有人会问，为什么不预先将所有的字节码编译成机器码，执行的时候不是更快更省事吗？首先机器码是和平台强相关的，linux和unix就可能有很大的不同，何况是windows，预编译会让java失去夸平台这种优势。 其次，即时编译可以让jvm拿到更多的运行时数据，根据这些数据可以对字节码做更深层次的优化，这些是C++这种预编译语言做不到的，所以有时候你写出的java代码执行效率会比C++的高。
CopyOnWrite
CopyOnWrite写时复制，最早应该是源自linux系统，linux中在调用fork() 生成子进程时，子进程应该拥有和父进程一样的指令和数据，可能子进程会修改一些数据，为了避免污染父进程的数据，所以要给子进程单独拷贝一份。出于效率考虑，fork时并不会直接复制，而是等到子进程的各段数据需要写入才会复制一份给子进程，故此得名 写时复制 。
在计算机的世界里，读写的分布也是有很大的局部性的，大多数情况下读远大于写， 写时复制 的方式，可以减少大量不必要的复制，提升性能。 另外这种方式也不仅仅是用在linux内核中，java的concurrent包中也提供了CopyOnWriteArrayList CopyOnWriteArraySet。像Spark中的RDD也是用CopyOnWrite来减少不必要的RDD生成。
处理
上面列举了那么多局部性的应用，其实还有很多很多，我只是列举出了几个我所熟知的应用，虽然上面这些例子，我们都利用局部性得到了能效、成本上的提升。但有些时候它也会给我们带来一些不好的体验，更多的时候它其实就是一把双刃剑，我们如何识别局部性，利用它好的一面，避免它坏的一面？
识别
文章开头也说过，局部性其实就是一种概率的不均等性，所以只要概率不均等就一定存在局部性，因为很多时候这种概率不均太明显了，非常好识别出来，然后我们对大头做相应的优化就行了。但可能有些时候这种概率不均需要做很详细的计算才能发现，最后还得核对成本才能考虑是否值得去做，这种需要具体问题具体分析了。
如何识别局部性，很简单，看概率分布曲线，只要不是一条水平的直线，就一定存在局部性。
利用
发现局部性之后对我们而言是如何利用好这些局部性，用得好提升性能、节约资源，用不好局部性就会变成阻碍。而且不光是在计算机领域，局部性在非计算机领域也可以利用。
性能优化
上面列举到的很多应用其实就是通过局部性做一些优化，虽然这些都是别人已经做好的，但是我们也可以参考其设计思路。
恰巧最近我也在做我们一个java服务的性能优化，利用jstack、jmap这些java自带的分析工具，找出其中最吃cpu的线程，找出最占内存的对象。我发现有个redis数据查询有问题，因为每次需要将一个大字符串解析很多个键值对，中间会产生上千个临时字符串，还需要将字符串parse成long和double。redis数据太多，不可能完全放的内存里，但是这里的key有明显的局部性，大量的查询只会集中在头部的一些key上，我用一个LRU Cache缓存头部数据的解析结果，就可以减少大量的查redis+解析字符串的过程了。
另外也发现有个代码逻辑，每次请求会被重复执行几千次，耗费大量cpu，这种热点代码，简单几行改动减少了不必要的调用，最终减少了近50%的CPU使用。
非计算机领域
《高能人士的七个习惯》里提到了一种工作方式，将任务划分为重要紧急、不重要但紧急、重要但不紧急、不重要不紧急四种，这种划分方式其实就是按单位时间的重要度排序的，按单位时间的重要度越高收益越大。《The Effective Engineer》里直接用leverage(杠杆率)来衡量每个任务的重要性。这两种方法差不多是类似的，都是优先做高收益率的事情，可以明显提升你的工作效率。
这就是工作中收益率的局部性导致的，只要少数事情有比较大的收益，才值得去做。还有一个很著名的法则__82法则__，在很多行业、很多领域都可以套用，80%的xxx来源于20%的xxx ，80%的工作收益来源于20%的工作任务，局部性给我们的启示“永远关注最重要的20%” 。
避免
上面我们一直在讲如何通过局部性来提升性能，但有时候我们需要避免局部性的产生。 比如在大数据运算时，时常会遇到数据倾斜、数据热点的问题，这就是数据分布的局部性导致的，数据倾斜往往会导致我们的数据计算任务耗时非常长，数据热点会导致某些单节点成为整个集群的性能瓶颈，但大部分节点却很闲，这些都是我们需要极力避免的。
一般我们解决热点和数据切斜的方式都是提供过重新hash打乱整个数据让数据达到均匀分布，当然有些业务逻辑可能不会让你随意打乱数据，这时候就得具体问题具体分析了。感觉在大数据领域，局部性极力避免，当然如果没法避免你就得通过其他方式来解决了，比如HDFS中小文件单节点读的热点，可以通过减少加副本缓解。其本质上没有避免局部性，只增加资源缓解热点了，据说微博为应对明星出轨Redis集群也是采取这种加资源的方式。
参考资料
维基百科局部性原理
《计算机组成与设计》 David A.Patterson / John L.Hennessy
《深入浅出计算机组成原理》 极客时间 徐文浩
《深入理解计算机系统》 Randal E.Bryant / David O’Hallaron 龚奕利 / 雷迎春(译)
interactive latencies
Introduction to Graal 郑雨迪
