Java与CPU浅见
作为一个JAVA程序员我们也应该知道计算机是何如运行的,计算机本身是如何完成工作的。其实我很后悔大二的时候没有好好学习那些计算机底层的知识,把大部分是时间花费在那些花拳绣腿上。
一、CPU的基本单位是线程,我们编写的程序通过进程或者线程请求CPU进行处理,首先CPU会分配处理的时间片,处理的时候将操作数传递给CPU,最后处理的结果输出到‘本地变量’中,这个‘本地变量’及时我们说常说的‘栈’(先进后出)。为了提升性能那些数据将会被Cache到缓存当中,我们知道缓存有一级缓存、二级缓存和三级缓存。容量最大的是三级缓存也就是几十兆。缓存既然与CPU交互最快为什么容量那么小?百度百科的解释是:“由于一级缓存的技术难度和制造成本最高,提高容量所带来的技术难度增加和成本增加非常大,所带来的性能提升却不明显,性价比很低”,而且如果缓存的容量过大,就像内存一样就会涉及到很复杂的算法进行管理。
我们知道JAVA之所以能够实现“一次编写,到处运行”是因为有一个强大的JVM,在程序运行的时候会通过java的虚指令来完成JAVA虚拟机中的数据和对象的一些操作,最后根据不同的OS将这些虚指令翻译成OS真正的指令。
二、现在大多数的计算机都是多核的,就像多个人去处理一项任务一样。那么问题来了,当一个请求来的时候CPU是怎么知道的呢?当发起请求的时候是哪个CPU进行处理?一份数据同时被多个CPU操作,如何通知其他CPU我做了什么?
对于第一个问题我的想法是类似与键盘一样,监听器不断的对键盘进行扫描监听,如果这样CPU会非常的繁忙并且效率不高,这时有了“中断技术”,有了它CPU不用自己去问有没有请求来,而是需要请求的处理的设备发送出一个“请求中断”信号,这时CPU便会放下手头的工作去去处理这个请求。完整的过程是:请求中断→响应中断→关闭中断→保留断点→中断源识别→保护现场→中断服务子程序→恢复现场→中断返回。
第二个问题我的想法是由一个请求处理CPU来控制所有的请求操作,这样的有一些弊端,比如:当请求量很大的时候这个CPU估计会吃不消。那么不同的CPU处理不同的区域,用划分区域的方法。这样也有弊端:不同区域之间可能会互相通信。
三、CPU处理的速度是非常快的,这里就出现了Cache Line,Cache 一行或者多行。举一个例子:如果要遍历一个二维数组 int[][] a=new int[5][10]; 有两种方法进行遍历我们常用的是第一维作为外循环,第二维作为内循环;第二种相反,那么两种方法效率是否一致呢? 我平时也是乱来,不知道其中与CPU读取时有怎样的差距。刚才说的Cache Line是连续读入相邻的内存,JAVA数组中分配内存是先分配第一维,然后再分配第二维子数组,例如:int[2][1]和int[3][1]是位于不同的一个数组上的,所以用Cache Line到Cache到CPU缓存中的时候会连续的读入多个,如果用第二中方法读入,数据在不同的数组中也就是在内存中的区域不同,那么Cache Line就不会发挥出他的作用,最后便会一个一个的读入,变得很慢。
四、当数据以及Cache到缓存中以后,如果多个CPU都需要对这个数据进行处理,怎样保持各个CPU的读写一致性?就有了一个MESI协议(缓存一致性协议)。多个CPU通过总线相互连接,每个CPU除了要处理自己的请求之外还要监听总线上其他CPU的读写操作,通过监听自己的Cache做相应的处理,形成了虚共享。MESI我也不是很清楚,只知道几个基本的规则,1.一个CPU加载内存是专用的;2.当另一个CPU也加载了同一块内存时,那么此时两个CPU持有的信息将处于共享状态。
跟CPU相关的还有并发操作,并发还没认真专学习过,一直觉得自己用不上,其实并发随处可见,只是很多框架都帮我们处理好了。下次再谈并发吧,写的很粗糙,主要还是梳理思路和分享一些重要的东西。