神刀安全网

java在CPU中的一些个破事

其实写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在总线级别也会有共享区来控制一些内容,有读级别、写级别、内存级别等,在不同的场景下使得锁的粒度尽量降低,那么系统的性能不言而喻,很正常的结果。

本文就说到这里,闲扯了下,仅供参考!

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » java在CPU中的一些个破事

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址