簡介：?目前手機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[][] arr=data.Getitem();

System.out.println("arr0 is "+arr[0]+"arr1 is"+arr[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[][] arr=data.Getitem();

System.out.println("arr0 is "+arr[0][0]+"arr1 is"+arr[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 now=System.currentTimeMillis();

int max=100,min=0;

long a=0;

long b=0;

long c=0;

for(int j=0;j<10000000;j++){

int ran=(int)(Math.random()*(max-min)+min);

switch(ran){

case 0:

a++;

break;

case 1:

a++;

break;

default:

c++;

}

}

long diff=System.currentTimeMillis()-now;

System.out.println("a is "+a+"b is "+b+"c is "+c);

? ? ? ? }

}

其中隨機數其實是一個rpc遠程調用的返回，但是這段代碼總是莫名其妙的卡頓，為了復現這個卡頓，定位到這個代碼段也是通過友盟U-APM的卡頓分析找到的，想復現這個卡頓只需要我們再稍微把max范圍由調整為5。

public class Main {

? ? ? ? public static void main(String[] args) {

? ? ? ? ? ? ? ? ?long now=System.currentTimeMillis();

int max=5,min=0;

long a=0;

long b=0;

long c=0;

for(int j=0;j<10000000;j++){

int ran=(int)(Math.random()*(max-min)+min);

switch(ran){

case 0:

a++;

break;

case 1:

a++;

break;

default:

c++;

}

}

long diff=System.currentTimeMillis()-now;

System.out.println("a is "+a+"b is "+b+"c is "+c);

? ? ? ? }

}

那么運行時間就會有30%的下降，不過從我們分析的情況來看，代碼一平均每個隨機數有97%的概念要行2次判斷才能跳轉到最終的分支，總體的判斷語句執行期望為2*0.97+1*0.03約等于2，而代碼二有30%的概念只需要1次判斷就可以跳轉到最終分支，總體的判斷執行期望也就是0.3*1+0.6*2=1.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 now=System.currentTimeMillis();

int max=6,min=0;

HashMap<Integer,Integer> hMap = new HashMap<Integer,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 j=0;j<10000000;j++){

int ran=(int)(Math.random()*(max-min)+min);

int value = hMap.get(ran)+1;

hMap.replace(ran,value);

}

long diff=System.currentTimeMillis()-now;

System.out.println(hMap);

System.out.println("time is "+ diff);

? ? ? ? }

}

上述這段用哈希表的代碼雖然不如代碼一速度快，但是總體非常穩定，即使出現代碼二的情況也比較平穩。

經驗總結

一、有并發的終端編程一定要注意按照緩存行（64byte)對齊，不按照緩存行對齊的代碼就是每增加一個線程性能會損失20%。

二、重點關注switch、if-else分支的問題，一旦條件分支的取值條件有所變化，那么應該首選用哈希表結構，對于條件分支進行優化。

三、選擇一款好用的性能監測工具，如：友盟U-APM，不僅免費且捕獲類型較為全面，推薦大家使用。

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。?

?

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的终端卡顿优化的全记录的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。