制作网站的图片素材,昆明做企业网站哪家好,佛山做网站建设,wordpress多站批量发布简介#xff1a; 目前手机SOC的性能越来越少#xff0c;很多程序员在终端程序的开发过程中也不太注意性能方面的优化#xff0c;尤其是不注意对齐和分支优化#xff0c;但是这两种问题一旦出现所引发的问题#xff0c;是非常非常隐蔽难查的#xff0c;不过好在项目中用到…简介 目前手机SOC的性能越来越少很多程序员在终端程序的开发过程中也不太注意性能方面的优化尤其是不注意对齐和分支优化但是这两种问题一旦出现所引发的问题是非常非常隐蔽难查的不过好在项目中用到了移动端的性能排查神器友盟U-APM工具的支持下最终几个问题得到了圆满解决。
我们先来看对齐的问题对齐在没有并发竞争的情况下不会有什么问题编译器一般都会帮助程序员按照CPU字长进行对齐但这在终端多线程同时工作的情况下可能会隐藏着巨大的性能问题在多线程并发的情况下即使没有共享变量也可能会造成伪共享由于具体的代码涉密因此我们来看以下抽象后的代码。
public class Main { public static void main(String[] args) { final MyData data new MyData();
new Thread(new Runnable() {
public void run() {
data.add(0);
}
}).start(); new Thread(new Runnable() {
public void run() {
data.add(0);
}
}).start();
try{
Thread.sleep(100);
} catch (InterruptedException e){
e.printStackTrace();
} long[][] arrdata.Getitem();
System.out.println(arr0 is arr[0]arr1 isarr[1]); }
}
class MyData {
private long[] arr{0,0}; public long[] Getitem(){
return arr;
} public void add(int j){
for (;true;){
arr[j];
}
}
}
在这段代码中两个子线程执行类似任务分别操作arr数组当中的两个成员由于两个子线程的操作对象分别是arr[0]和arr[1]并不存在交叉的问题因此当时判断判断不会造成并发竞争问题也没有加synchronized关键字
但是这段程序却经常莫名的卡顿后来经过多方的查找并最终通过友盟的卡顿分析功能我们最终定位到了上述代码段发现这是一个由于没有按照缓存行进行对齐而产生的问题这里先将修改完成后的伪代码向大家说明一下
public class Main { public static void main(String[] args) { final MyData data new MyData();
new Thread(new Runnable() {
public void run() {
data.add(0);
}
}).start(); new Thread(new Runnable() {
public void run() {
data.add(0);
}
}).start();
try{
Thread.sleep(10);
} catch (InterruptedException e){
e.printStackTrace();
} long[][] arrdata.Getitem();
System.out.println(arr0 is arr[0][0]arr1 isarr[1][0]); }
}
class MyData {
private long[][] arr{{0,0,0,0,0,0,0,0,0},{0,0}}; public long[][] Getitem(){
return arr;
} public void add(int j){
for (;true;){
arr[j][0];
}
}
}
可以看到整体程序没有作何变化只是将原来的数组变成了二维数组其中除了第一个数组中除arr[0][0]元素外其余arr[0][1]-a[0][8]元素除完全不起作何与程序运行有关的作用但就这么一个小小的改动却带来了性能有了接近20%的大幅提升如果并发更多的话提升幅度还会更加明显。
缓存行对齐排查分析过程
首先我们把之前代码的多线程改为单线程串行执行结果发现效率与原始的代码一并没有差很多这就让我基本确定了这是一个由伪共享引发的问题但是我初始代码中并没有变量共享的问题所以这基本可以判断是由于对齐惹的祸。
现代的CPU一般都不是按位进行内存访问而是按照字长来访问内存当CPU从内存或者磁盘中将读变量载入到寄存器时每次操作的最小单位一般是取决于CPU的字长。比如8位字是1字节那么至少由内存载入1字节也就是8位长的数据再比如32位CPU每次就至少载入4字节数据, 64位系统8字节以此类推。那么以8位机为例咱们来看一下这个问题。假如变量1是个bool类型的变量它占用1位空间而变量2为byte类型占用8位空间假如程序目前要访问变量2那么第一次读取CPU会从开始的0x00位置读取8位也就是将bool型的变量1与byte型变量2的高7位全部读入内存但是byte变量的最低位却没有被读进来还需要第二次的读取才能把完整的变量2读入。
也就是说变量的存储应该按照CPU的字长进行对齐当访问的变量长度不足CPU字长的整数倍时需要对变量的长度进行补齐。这样才能提升CPU与内存间的访问效率避免额外的内存读取操作。但在对齐方面绝大多数编译器都做得很好在缺省情况下C编译器为每一个变量或是数据单元按其自然对界条件分配空间边界。也可以通过pragma pack(n)调用来改变缺省的对界条件指令调用后C编译器将按照pack(n)中指定的n来进行n个字节的对齐这其实也对应着汇编语言中的.align。那么为什么还会有伪共享的对齐问题呢
现代CPU中除了按字长对齐还需要按照缓存行对齐才能避免并发环境的竞争目前主流ARM核移动SOC的缓存行大小是64byte因为每个CPU都配备了自己独享的一级高速缓存一级高速缓存基本是寄存器的速度每次内存访问CPU除了将要访问的内存地址读取之外还会将前后处于64byte的数据一同读取到高速缓存中而如果两个变量被放在了同一个缓存行那么即使不同CPU核心在分别操作这两个独立变量而在实际场景中CPU核心实际也是在操作同一缓存行这也是造成这个性能问题的原因。
Switch的坑
但是处理了这个对齐的问题之后我们的程序虽然在绝大多数情况下的性能都不错但是还是会有卡顿的情况结果发现这是一个由于Switch分支引发的问题。
switch是一种我们在java、c等语言编程时经常用到的分支处理结构主要的作用就是判断变量的取值并将程序代码送入不同的分支这种设计在当时的环境下非常的精妙但是在当前最新的移动SOC环境下运行却会带来很多意想不到的坑。
出于涉与之前密的原因一样真实的代码不能公开我们先来看以下这段代码
public class Main { public static void main(String[] args) { long nowSystem.currentTimeMillis();
int max100,min0;
long a0;
long b0;
long c0;
for(int j0;j10000000;j){
int ran(int)(Math.random()*(max-min)min);
switch(ran){
case 0:
a;
break;
case 1:
a;
break;
default:
c;
}
}
long diffSystem.currentTimeMillis()-now;
System.out.println(a is ab is bc is c); }
}
其中随机数其实是一个rpc远程调用的返回但是这段代码总是莫名其妙的卡顿为了复现这个卡顿定位到这个代码段也是通过友盟U-APM的卡顿分析找到的想复现这个卡顿只需要我们再稍微把max范围由调整为5。
public class Main { public static void main(String[] args) { long nowSystem.currentTimeMillis();
int max5,min0;
long a0;
long b0;
long c0;
for(int j0;j10000000;j){
int ran(int)(Math.random()*(max-min)min);
switch(ran){
case 0:
a;
break;
case 1:
a;
break;
default:
c;
}
}
long diffSystem.currentTimeMillis()-now;
System.out.println(a is ab is bc is c); }
}
那么运行时间就会有30%的下降不过从我们分析的情况来看代码一平均每个随机数有97%的概念要行2次判断才能跳转到最终的分支总体的判断语句执行期望为2*0.971*0.03约等于2而代码二有30%的概念只需要1次判断就可以跳转到最终分支总体的判断执行期望也就是0.3*10.6*21.5,但是代码二却反比代码一还慢30%。也就是说在代码逻辑完全没变只是返回值范围的概率密度做一下调整就会使程序的运行效率大大下降要解释这个问题要从指令流水线说起。
指令流水线原理
我们知道CPU的每个动作都需要用晶体震荡而触发以加法ADD指令为例想完成这个执行指令需要取指、译码、取操作数、执行以及取操作结果等若干步骤而每个步骤都需要一次晶体震荡才能推进因此在流水线技术出现之前执行一条指令至少需要5到6次晶体震荡周期才能完成
为了缩短指令执行的晶体震荡周期芯片设计人员参考了工厂流水线机制的提出了指令流水线的想法由于取指、译码这些模块其实在芯片内部都是独立的完成可以在同一时刻并发执行那么只要将多条指令的不同步骤放在同一时刻执行比如指令1取指指令2译码指令3取操作数等等就可以大幅提高CPU执行效率
以上图流水线为例 在T5时刻之前指令流水线以每周期一条的速度不断建立在T5时代以后每个震荡周期都可以有一条指令取结果平均每条指令就只需要一个震荡周期就可以完成。这种流水线设计也就大幅提升了CPU的运算速度。
但是CPU流水线高度依赖指指令预测技术假如在流水线上指令5本是不该执行的但却在T6时刻已经拿到指令1的结果时才发现这个预测失败那么指令5在流水线上将会化为无效的气泡如果指令6到8全部和指令5有强关联而一并失效的话那么整个流水线都需要重新建立。 所以可以看出例子当中的这个效率差完全是CPU指令预测造成的也就是说CPU自带的机制就是会对于执行概比较高的分支给出更多的预测倾斜。
处理建议-用哈希表替代switch
我们上文也介绍过哈希表也就是字典可以快速将键值key转化为值value从某种程度上讲可以替换switch的作用按照第一段代码的逻辑用哈希表重写的方案如下
import java.util.HashMap;
public class Main { public static void main(String[] args) { long nowSystem.currentTimeMillis();
int max6,min0;
HashMapInteger,Integer hMap new HashMapInteger,Integer();
hMap.put(0,0);
hMap.put(1,0);
hMap.put(2,0);
hMap.put(3,0);
hMap.put(4,0);
hMap.put(5,0);
for(int j0;j10000000;j){
int ran(int)(Math.random()*(max-min)min);
int value hMap.get(ran)1; hMap.replace(ran,value);
} long diffSystem.currentTimeMillis()-now;
System.out.println(hMap);
System.out.println(time is diff); }
}
上述这段用哈希表的代码虽然不如代码一速度快但是总体非常稳定即使出现代码二的情况也比较平稳。
经验总结
一、有并发的终端编程一定要注意按照缓存行64byte)对齐不按照缓存行对齐的代码就是每增加一个线程性能会损失20%。
二、重点关注switch、if-else分支的问题一旦条件分支的取值条件有所变化那么应该首选用哈希表结构对于条件分支进行优化。
三、选择一款好用的性能监测工具如友盟U-APM不仅免费且捕获类型较为全面推荐大家使用。
原文链接 本文为阿里云原创内容未经允许不得转载。
