其实写java的人貌似和cpu没啥关系，最多最多和我们在前面提及到的如何将cpu跑满、如何设置线程数有点关系，但是那个算法只是一个参考，很多场景不同需要采取实际的手段来解决才可以；而且将cpu跑满后我们还会考虑如何让cpu不是那么满，呵呵，人类，就是这么xx，呵呵，好了，本文要说的是其他的一些东西，也许你在java的写代码时几乎不用关注cpu，因为满足业务才是第一重要的事情，如果你要做到框架级别，为框架提供很多共享数据缓存之类的东西，中间必然存在很多数据的征用问题，当然java提供了很多concurrent包的类，你可以用它，但是它内部如何做的，你要明白细节才能用得比较好，否则还不如不用，本文可能不是阐述这些内容作为重点，因为如标题党：我们要说cpu，呵呵。
还是那句话，貌似java和cpu没有多少关系，我们现在来聊聊有啥关系；
1、当遇到共享元素，我们通常第一想法是通过volatile来保证一致性读的操作，也就是绝对的可见性，所谓可见性，就是每次要使用该数据的时候，cpu不会使用任何cache的内容都会从内存中去抓取一次数据，并且这个过程对多cpu仍然有效，也就是相当cpu和内存之间此时是同步的，cpu会像总线发出一个lock addl 0类似的的汇编指令，+0但相对于什么都不会做；不过一旦该指令完成，后续操作将不再影响这个元素其他线程的访问，也就是他能实现的绝对可见性，但是不能实现一致性操作，也就是说，volatile不能实现的是i++这类操作的一致性（在多线程下并发），因为i++操作是被分解为：
int tmp = i; tmp = tmp + 1; i = tmp;
这三个步骤来完成，从这点你也能看出i++为什么能实现先做其他的事情再自我加1，因为它讲值赋予给了另一个变量。
2、我们要用到多线程并发一致性，就需要用到锁的机制，目前类似atomic*的东西基本可以满足这些要求，内部提供了很多unsafe类的方法，通过不断对比绝对可见性的数据来保证获取的数据是最新的；接下来我们继续来说一些cpu其他的事情。
3、以前我们为了将cpu跑满，但是无论如何跑不满，因为我们开始说了忽略掉内存与cpu的延迟，今天既然提及到这儿，我们就简单说下延迟，一般来讲现在的cpu有三级cache，年代不同延迟不同，所以具体数字只能说个大概而已，现在的cpu一般一级cache的延迟在1-2ns，二级cache一般是几个ns到十来ns左右，三级cache一般是30ns到50ns不等，内存访问普遍会上到70ns甚至更多（计算机发展速度很快，这个值也仅仅在某些cpu上的数据，做一个范围参考而已）；别看这个延迟很小，都是纳秒级别，你会发现你的程序被拆分为指令运算的时候，会有很多cpu交互，每次交互的延迟如果有这么大的偏差，此时系统性能是会有变化的；
4、回到刚才说的volatile，它每次从内存中获取数据，就是放弃cache，自然如果在某些单线程的操作中，会变得更加慢，有些时候我们也不得不这样做，甚至于读写操作都要求一致性，甚至于整个数据块都被同步，我们只能在一定程度上降低锁的粒度，但是不能完全没有锁，即使是cpu本身级别也会有指令级别的限制。
5、在cpu本身级别的原子操作一般叫屏障，有读屏障、写屏障等，一般是基于一个点的触发，当程序多条指令发送到cpu的时候，有些指令未必是按照程序的顺序来执行，有些必须按照程序的顺序来执行，只要能最终保证一致即可；在排序上，jit在运行时会做改变，cpu指令级别也会做改变，原因主要是为了优化运行时指令让程序跑得更快。
6、cpu级别会对内存做cache line的操作，所谓cache line会连续读一块内存，一般和cpu型号和架构有关系，现在很多cpu每次读取连续内存一般是64byte，早期的有32byte的，所以在某些数组遍历的时候会比较快（基于列遍历很慢），但这个并不完全对，下面会对照一些相反的情况来说。
7、cpu对数据如果发生了修改，此时就不得不说cpu对数据修改的状态，数据如果都被读取，在多cpu下可以被多线程并行读取并，当对数据块发生写操作的时候，就不一样了，数据块会有独占、修改、失效等状态，数据修改后自然就会失效，当在多cpu下，多个线程都在对同一个数据块进行修改时，就会发生cpu之间的总线数据拷贝（qpi），当然如果修改到同一个数据上的时候我们是没有办法的，但是回到第6点的cache line里面，问题就比较麻烦了，如果数据是在同一个数组上，而数组中的元素会被同时cache line到一个cpu上的时候，多线程的qpi就会非常频繁，有些时候即使是数组上组装的是对象也会出现这个问题，如：
我要评论
class inputinteger {
private int value;
public inputinteger(int i) {
this.value = i;
}
}
inputinteger[] integers = new inputinteger[size];
for(int i=0 ; i < size ; i++) {
integers[i] = new inputinteger(i);
}
此时你看出来integers里面放的全部是对象，数组上只有对象的引用，但是对象的排布理论上说各自对象是独立的，不会连续存放，不过java在分配对象内存的时候，很多时候，在eden区域是连续分配的，当在for循环的时候，如果没有其他线程的接入，这些对象就会被存放在一起，即使被gc到old区域也很有可能会放在一起，所以靠简单对象来解决cache line后还对整个数组修改的方式貌似不靠谱，因为int 是4字节，如果在64模式下，这个大小是24字节（有4byte补齐），指针压缩开启是16byte；也就是每次cpu可以看齐3-4个对象，如何让cpucache了，但是又不影响系统的qpi，别想通过分隔对象来完成，因为gc过程内存拷贝过程很可能会拷贝到一起，最好的办法是补齐，虽然有点浪费内存，但是这是最靠谱的方法，就是将对象补齐到64字节，上述若未开启指针压缩有24byte，此时还有40个字节，只需要在对象内部增加5个long即可。
class inputinteger {
public int value;
private long a1,a2,a3,a4,a5;
}
呵呵，这个办法很土，不过很管用，有些时候，jvm编译的时候发现这几个参数啥都没做，就直接给你干掉了，优化无效，土办法加土办法就是在一个方法体里面简单对这5个参数做一个操作（都用上），但是这个方法永远不调用它即可。
8、在cpu这个级别有些时候就未必能先做尽量先做的道理为王者了，类似获取锁这种操作，在atomicintegerfieldupdater的操作，如果调用getandset(true)在单线程下你会发现跑得还蛮快，在多核cpu下就开始变慢，为什么上面说得很清楚了，因为getandset里面是修改后对比，先改了再说，qpi会很高，所以这个时候，先做get操作，再修改才是比较好的做法；还有就是获取一次，如果获取不到，就让步一下，让其他的线程去做其他的事情；
9、cpu有些时候为了解决某些cpu忙和不繁忙的问题，会有很多算法来解决，如numa是其中一种方案，不过不论哪种架构都在一定场景下比较有用，对有所有场景未必有效；有队列锁机制来完成对cpu状态管理，不过这又存在了cache line的问题，因为状态都是经常改变的，各类应用程序的内核为了配合cpu也会出一些算法来做，使得cpu可以更加有效的利用起来，如clh队列等。
有关这方面的细节会很多如用普通变量循环叠加和用volatile类型的做以及atomic*系列的来做，完全是不一样的；多维度数组循环，按照不同纬度向后次序来循环也是不一样的，细节上点很多，明白为什么就在实际优化过程中有灵感了；锁的细节说太细很晕，在系统底层的级别，始终有一些轻量级的原子操作，不论谁说他的代码是不需要加锁的，最细的可以细到cpu在每个瞬间只能执行一条指令那么简单，多核心cpu在总线级别也会有共享区来控制一些内容，有读级别、写级别、内存级别等，在不同的场景下使得锁的粒度尽量降低，那么系统的性能不言而喻，很正常的结果。
如对本文有疑问， 点击进行留言回复！！
【性能】Android中的内存溢出（Out Of Memory，OOM）
android framework层input事件接收和派发
网友评论