性能優化是個系統性工程,巨集觀上可分為網路,服務,存儲幾個方向,每個方向又可以細分為架構,設計,代碼,可用性,度量等多個子項。 本文將重點從代碼和設計兩個子項展開,談談那些提升性能的知識點。 ...
一 前言
服務性能是指服務在特定條件下的響應速度、吞吐量和資源利用率等方面的表現。據統計,性能優化方面的精力投入,通常占軟體開發周期的10%到25%左右,當然這和應用的性質和規模有關。性能對提高用戶體驗,保證系統可靠性,降低資源使用率,甚至增強市場競爭力等方面,都有著很大的影響。
性能優化是個系統性工程,巨集觀上可分為網路,服務,存儲幾個方向,每個方向又可以細分為架構,設計,代碼,可用性,度量等多個子項。 本文將重點從代碼和設計兩個子項展開,談談那些提升性能的知識點。當然,很多性能提升策略都是有代價的,適用於某些特定場景,大家在學習和使用的時候,最好帶著批判的思維,決策前,做好利弊權衡。
先簡單羅列一下性能優化方向:
二 代碼優化
2.1 關聯代碼
關聯代碼優化是通過預載入相關代碼,避免在運行時載入目標代碼,造成運行時負擔。我們知道Java有兩個類載入器:Bootstrap class loader和Application class loader。Bootstrap class loader負責載入Java API中包含的核心類,而Application class loader則負責載入自定義類。關聯代碼優化可以通過以下幾種方式來實現。
預載入關聯
預載入關聯類是指在程式啟動時預先載入目標與關聯類,以避免在運行時載入。可以通過靜態代碼塊來實現預載入,如下所示:
public class MainClass {
static {
// 預載入MyClass,其實現了相關功能
Class.forName("com.example.MyClass");
}
// 運行相關功能的代碼
// ...
}
使用線程池
線程池可以讓多個任務使用同一個線程池中的線程,從而減少線程的創建和銷毀成本。使用線程池時,可以在程式啟動時創建線程池,併在主線程中預載入相關代碼。然後以非同步方式使用線程池中的線程來執行相關代碼,可以提高程式的性能。
使用靜態變數
可以使用靜態變數來緩存與關聯代碼有關的對象和數據。在程式啟動時,可以預先載入關聯代碼,並將對象或數據存儲在靜態變數中。然後在程式運行時使用靜態變數中緩存的對象或數據,以避免重覆載入和生成。這種方式可以有效地提高程式的性能,但需要註意靜態變數的使用,確保它們在多線程環境中的安全性。
2.2 緩存對齊
在介紹緩存對齊之前,需要先普及一些CPU指令執行的相關知識。
- 緩存行(Cache line) : CPU讀取記憶體數據時並非一次只讀一個位元組,一般是會讀一段64位元組(硬體決定)長度的連續的記憶體塊(chunks of memory),這些塊我們稱之為緩存行。
- 偽共用(False Sharing):當運行在兩個不同CPU上的兩個線程寫入兩個不同的變數時,如果這兩個變數恰好存儲在同一個 CPU 緩存行中,就會發生偽共用(False Sharing)。即當第一個線程修改緩存行中其中一個變數時,其他引用此緩存行變數的線程的緩存行將會無效。如果CPU需要讀取失效的緩存行,它必須等待緩存行刷新,這會導致性能下降。
- CPU停止運轉(stall):當一個核心需要等待另一個核心重新載入緩存行時(出現偽共用時),它無法繼續執行下一條指令,只能停止運轉等待,這被稱之為stall。減少偽共用也就意味著減少了stall的發生。
- IPC(instructions per cycle):它表示平均每個 CPU 周期執行的指令數量,很顯然該數值越大性能越好。可以基於IPC指標(比如:閾值1.0)來簡單判斷程式是屬於訪問密集型還是計算密集型。Linux系統中可以通過tiptop命令來查看每個進程的CPU硬體數據:
如何簡單來區分訪存密集型和計算密集型程式?
-
如果 IPC < 1.0, 很可能是 Memory stall 占主導,多半意味著訪存密集型。
-
如果IPC > 1.0, 很可能是計算密集型的程式。
- CPU利用率:是指系統中CPU處於忙碌狀態的時間與總時間的比例。忙碌狀態時間又可以進一步拆分為指令(instruction)執行消耗周期cycle(%INS) 和 stalled 的周期cycle(%STL)。perf 採集了10秒內全部 CPU 的運行狀態:
IPC計算
IPC = instructions/cycles
上圖中,可以計算出結果為:0.79
現代處理器一般有多條流水線(比如:4核心),運行 perf 的那台機器,IPC的理論值可達到4.0。
如果我們從 IPC的角度來看,這台機器只運行到其處理器最高速度的 19.7%(0.79 / 4.0)。
總之,通過Top命令,看到CPU使用率之後,可以進一步分析指令執行消耗周期和 stalled 周期,有這些更詳細的指標之後,就能夠知道該如何更好地對應用和系統進行調優。
- 緩存對齊: 是通過調整數據在記憶體中的分佈,讓數據在被緩存時,更有利於CPU從緩存中讀取,從而避免了頻繁的記憶體讀取,提高了數據訪問的速度。
緩存填充(Padding)
減少偽共用也就意味著減少了stall的發生,其中一個手段就是通過填充(Padding)數據的形式,即在適當的距離處插入一些對齊的空間來填充緩存行,從而使每個線程的修改不會臟污同一個緩存行。
/**
* 緩存行填充測試
*
* @author liuhuiqing
* @date 2023年04月28日
*/
public class FalseSharingTest {
private static final int LOOP_NUM = 1000000000;
public static void main(String[] args) throws InterruptedException {
Struct struct = new Struct();
long start = System.currentTimeMillis();
Thread t1 = new Thread(() -> {
for (int i = 0; i < LOOP_NUM; i++) {
struct.x++;
}
});
Thread t2 = new Thread(() -> {
for (int i = 0; i < LOOP_NUM; i++) {
struct.y++;
}
});
t1.start();
t2.start();
t1.join();
t2.join();
System.out.println("cost time [" + (System.currentTimeMillis() - start) + "] ms");
}
static class Struct {
// 共用變數
volatile long x;
// 一個long占用8個位元組,此處定義7個填充數據,來保證業務數據x和y分佈在不同的緩存行中
long p1, p2, p3, p4, p5, p6, p7;
// long[] paddings = new long[7];// 使用數組代替不會生效,思考一下,為什麼?
// 共用變數
volatile long y;
}
}
經過本地測試,這種以空間換時間的方式,即實現了緩存行數據對齊的方式,在執行效率方面,比沒有對齊之前,提高了5倍!
@Contended註解
在Java 8中,引入了@Contended註解,該註解可以用來告訴JVM對欄位進行緩存對齊(將欄位放入不同的緩存行),從而提高程式的性能。使用@Contended註解時,需要在JVM啟動時添加參數-XX:-RestrictContended,實現如下所示:
import sun.misc.Contended;
public class ContendedTest {
@Contended
volatile long a;
@Contended
volatile long b;
public static void main(String[] args) throws InterruptedException {
ContendedTest c = new ContendedTest();
Thread thread1 = new Thread(() -> {
for (int i = 0; i < 10000_0000L; i++) {
c.a = i;
}
});
Thread thread2 = new Thread(() -> {
for (int i = 0; i < 10000_0000L; i++) {
c.b = i;
}
});
final long start = System.nanoTime();
thread1.start();
thread2.start();
thread1.join();
thread2.join();
System.out.println((System.nanoTime() - start) / 100_0000);
}
}
對齊記憶體與本地變數
緩存填充是解決CPU偽共用問題的解決方案之一,在實際應用中,是否還有其它方案來解決這一問題呢?答案是有的:即對齊記憶體和本地變數。
- 對齊記憶體:記憶體行的大小一般為64個位元組,這個大小是硬體決定的,但大多數編譯器預設情況下都以4位元組的邊界對齊,通過將變數按照記憶體行的大小對齊,可以避免偽共用問題;
- 本地變數:在不同線程之間使用不同的變數存儲數據,避免不同的線程之間共用同一塊記憶體,Java中的ThreadLocal就是一種典型的實現方式;
2.3 分支預測
分支預測是CPU動態執行技術中的主要內容,是通過猜測程式中的分支語句(如if-else語句或者迴圈語句)的執行路徑來提高CPU執行效率的技術。其原理是根據之前的歷史記錄和統計數據,預測程式下一步要執行的指令是分支跳轉指令還是順序執行指令,從而提前載入相關數據,減少CPU等待指令執行的空閑時間。預測準確率越高,CPU的性能提升就越高。那麼如何提高預測的準確率呢?
- 關註圈複雜度
過多的條件語句和嵌套的條件語句會導致分支的預測難度大幅上升,從而降低分支預測的準確率和效率。一般來說,可以通過優化代碼邏輯結構、減少冗餘等方式來避免過多的條件語句和嵌套的條件語句。
- 優先處理常用路徑
在編寫代碼時,應該優先處理常用路徑,以減少CPU對分支的預測,提高預測準確率和效率。例如,在if-else語句中,應該將常用的路徑放在if語句中,而將不常用的路徑放在else語句中。
2.4 寫時複製
Copy-On-Write (COW)是一種記憶體管理機制,也被稱為寫時複製。其主要思想是在需要寫入數據時,先進行數據拷貝,然後再進行操作,從而避免了對數據進行不必要的複製和操作。COW機制可以有效地降低記憶體使用率,提高程式的性能。
在創建進程或線程的時候,操作系統為其分配記憶體時,不是複製一個完整的物理地址空間,而是創建一個指向父進程/線程物理地址空間的虛擬地址空間,併為它們的所有頁面設置"只讀"標誌。當子進程/線程需要修改頁面時,會觸發一個缺頁異常,並將涉及到的頁面進行數據的複製,併為複製的頁面重新分配記憶體。子進程/線程只能夠操作複製後的地址空間,父進程/線程的原始記憶體空間則被保留。
由於COW機制在寫入之前進行數據拷貝,所以可以有效地避免頻繁的記憶體拷貝和分配操作,降低了記憶體的占用率,提高了程式的性能。並且,COW機制也避免了數據的不必要複製,從而減少了記憶體的消耗和記憶體碎片的產生,提高了系統中可用記憶體的數量。
ArrayList類可以使用Copy-On-Write機制來提高性能。
// 初始化數組
private List<String> list = new CopyOnWriteArrayList<>();
// 向數組中添加元素
list.add("value");
需要註意的是,Copy-On-Write機制適用於讀操作比寫操作多的情況,因為它假定寫操作的頻率較低,從而可以通過犧牲複製的開銷來減少鎖的操作和記憶體分配的消耗。
2.5 內聯優化
在Java中,每次調用方法都需要進行一些額外的操作,例如創建堆棧幀、保存寄存器狀態等,這些額外的操作會消耗一定的時間和記憶體資源。內聯優化是一種編譯器優化技術,Java虛擬機通常使用即時編譯器(JIT)來進行方法內聯,用於提高程式的性能。內聯優化的目標是將函數的調用替換成函數本身的代碼,以減少函數調用的開銷,從而提高程式的運行效率。
需要註意的是,方法內聯並不是在所有情況下都能夠提高程式的運行效率。如果方法內聯導致代碼複雜度增加或者記憶體占用增加,反而會降低程式的性能。因此,在使用方法內聯時需要根據具體情況進行權衡和優化。
final修飾符
final修飾符可以使方法成為不可重寫的方法。因為不可重寫,所以在編譯器優化時可以將它們的代碼嵌入到調用它們的代碼中,從而避免函數調用的開銷。使用final修飾符可以在一定程度上提高程式的性能,但同時也減弱了代碼的可擴展性。
限制方法長度
方法的長度會影響其在編譯時能否被內聯。通常情況下,長度較小的方法更容易被內聯。因此,可以在設計中將代碼分解和重構為更小的函數。這種方式並不是100%確保可以內聯,但至少提高了實現此優化的機會。內聯調優參數,如下表格:
JVM參數 | 預設值 (JDK 8, Linux x86_64) | 參數說明 |
---|---|---|
-XX:MaxInlineSize= |
35 位元組碼 | 內聯方法大小上限 |
-XX:FreqInlineSize= |
325 位元組碼 | 內聯熱方法的最大值 |
-XX:InlineSmallCode= |
1000位元組的原生代碼(非分層) 2000位元組的原生代碼(分層編譯) | 如果最後一層的的分層編譯代碼量已經超過這個值,就不進行內聯編譯 |
-XX:MaxInlineLevel= |
9 | 調用層級比這個值深的話,就不進行內聯 |
內聯註解
在Java 5之後,引入了內聯註解@inline,使用此註解可以在編譯時通知編譯器,將該方法內聯到它的調用處。註解@inline在Java 9之後已經被棄用,可以使用@ForceInline註釋來替代,同時設置JVM參數:
-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+JVMCICompiler
@ForceInline
public static int add(int a, int b) {
return a + b;
}
2.6 編碼優化
反射機制
Java反射在一定程度上會影響性能,因為它需要在運行時進行類型檢查轉換和方法查找,這比直接調用方法會更耗時。此外,反射也不會受到編譯器的優化,因此可能會導致更慢的代碼執行速度。
要解決這個問題有以下幾種方式:
- 儘可能使用原生方法調用,而不是通過反射調用;
- 儘可能緩存反射調用結果,避免重覆調用。例如,可以將反射結果緩存到靜態變數中,以便下次使用時直接獲取,而不必再次使用反射;
- 使用位元組碼增強技術;
下麵著重介紹一下反射結果緩存和位元組碼增強兩種方案。
- 反射結果緩存可以大幅減少反射過程中的類型檢查,類型轉換和方法查找等動作,是降低反射對程式執行效率影響的一種優化策略。
/**
* 反射工具類
*
* @author liuhuiqing
* @date 2023年5月7日
*/
public abstract class BeanUtils {
private static final Logger LOGGER = LoggerFactory.getLogger(BeanUtils.class);
private static final Field[] NO_FIELDS = {};
private static final Map<Class<?>, Field[]> DECLARED_FIELDS_CACHE = new ConcurrentReferenceHashMap<Class<?>, Field[]>(256);
private static final Map<Class<?>, Field[]> FIELDS_CACHE = new ConcurrentReferenceHashMap<Class<?>, Field[]>(256);
/**
* 獲取當前類及其父類的屬性數組
*
* @param clazz
* @return
*/
public static Field[] getFields(Class<?> clazz) {
if (clazz == null) {
throw new IllegalArgumentException("Class must not be null");
}
Field[] result = FIELDS_CACHE.get(clazz);
if (result == null) {
Field[] fields = NO_FIELDS;
Class<?> searchType = clazz;
while (Object.class != searchType && searchType != null) {
Field[] tempFields = getDeclaredFields(searchType);
fields = mergeArray(fields, tempFields);
searchType = searchType.getSuperclass();
}
result = fields;
FIELDS_CACHE.put(clazz, (result.length == 0 ? NO_FIELDS : result));
}
return result;
}
/**
* 獲取當前類屬性數組(不包含父類的屬性)
*
* @param clazz
* @return
*/
public static Field[] getDeclaredFields(Class<?> clazz) {
if (clazz == null) {
throw new IllegalArgumentException("Class must not be null");
}
Field[] result = DECLARED_FIELDS_CACHE.get(clazz);
if (result == null) {
result = clazz.getDeclaredFields();
DECLARED_FIELDS_CACHE.put(clazz, (result.length == 0 ? NO_FIELDS : result));
}
return result;
}
/**
* 數組合併
*
* @param array1
* @param array2
* @param <T>
* @return
*/
public static <T> T[] mergeArray(final T[] array1, final T... array2) {
if (array1 == null || array1.length < 1) {
return array2;
}
if (array2 == null || array2.length < 1) {
return array1;
}
Class<?> compType = array1.getClass().getComponentType();
int newArrLength = array1.length + array2.length;
T[] newArr = (T[]) Array.newInstance(compType, newArrLength);
int firstArrayLen = array1.length;
System.arraycopy(array1, 0, newArr, 0, firstArrayLen);
try {
System.arraycopy(array2, 0, newArr, firstArrayLen, array2.length);
} catch (ArrayStoreException ase) {
final Class<?> type2 = array2.getClass().getComponentType();
if (!compType.isAssignableFrom(type2)) {
throw new IllegalArgumentException("Cannot store " + type2.getName() + " in an array of "
+ compType.getName(), ase);
}
throw ase;
}
return newArr;
}
}
- 位元組碼增強技術,一般使用第三方庫來實現,例如Javassist或Byte Buddy,在運行時生成位元組碼,從而避免使用反射。
為什麼動態位元組碼生成方式相比反射也可以提高執行效率呢?
- 動態位元組碼生成的方式在編譯期就已經將類型信息確定下來,無需進行類型檢查和轉換;
- 動態位元組碼生成的方式可以直接調用方法,無需查找,提高了執行效率;
- 動態位元組碼生成的方式只需要在生成位元組碼時獲取一次Method對象,多次調用時可以直接使用,避免了重覆獲取Method對象的開銷;
這裡就不再舉例說明瞭,感興趣的同學可以自行查閱資料進行深入學習。
異常處理
有效的處理異常可以保證程式的穩定性和可靠性。但異常的處理對性能還是有一定的影響的,這一點常常被人忽視。影響性能的具體表現為:
- 響應延遲:當異常被拋出時,Java虛擬機需要查找並執行相應的異常處理程式,這會導致一定的延遲。如果程式中存在大量的異常處理,這些延遲可能會累積,導致程式的整體性能下降。
- 記憶體占用:異常處理需要在堆棧中創建異常對象,這些對象需要占用記憶體。如果程式中存在大量的異常處理,這些異常對象可能會占用大量的記憶體,導致程式的整體記憶體占用量增加。
- CPU占用:異常處理需要執行額外的代碼,這會導致CPU占用率增加。如果程式中存在大量的異常處理,這些額外的代碼可能會導致CPU占用率過高,導致程式的整體性能下降。
一些基準測試顯示,異常處理可能會導致程式的性能下降幾個百分點。在Java虛擬機規範中提到,在沒有異常發生的情況下,基於堆棧的方法調用可能比基於異常的方法調用快2-3倍。此外,一些實驗表明,在異常處理程式中使用大量的try-catch語句,可能會導致性能下降10倍以上。
為避免這些問題,在編寫代碼時謹慎地使用異常處理機制,並確保對異常進行適當的記錄和報告,避免過度使用異常處理機制。
日誌處理
先看以下代碼:
LOGGER.info("result:" + JsonUtil.write2JsonStr(contextAdContains) + ", logid = " + DigitThreadLocal.getLogId());
以上示例代碼中,類似的日誌列印方式很常見,難道有什麼問題嗎?
- 性能問題:每次使用+進行字元串拼接時,都會創建一個新的字元串對象,這可能會導致記憶體分配和垃圾回收的開銷增加;
- 可讀性問題:使用+進行字元串拼接時,代碼可能會變得難以閱讀和理解,特別是在需要連接多個字元串時;
- 如果日誌級別調整到ERROR模式,我們希望日誌的字元串內容不需要進行加工計算,但這種寫法,即使日誌處於不需要列印的模式,日誌內容也進行了無效計算;
特別實在請求量和日誌列印量比較高的場景下,日誌內容的序列化和寫文件操作,對服務的耗時影響可以達到10%,甚至更多。
臨時對象
臨時對象通常是指在方法內部創建的對象。大量創建臨時對象會導致Java虛擬機頻繁進行垃圾回收,從而影響程式的性能。也會占用大量的記憶體空間,從而導致程式崩潰或者出現記憶體泄漏等問題。
為了避免大量創建臨時對象,在編碼時,可以採取以下措施:
- 字元串拼接中,使用StringBuilder或StringBuffer進行字元串拼接,避免使用連接符,每次都創建新的字元串對象;
- 在集合操作中,儘量使用批量操作,如addAll、removeAll等,避免頻繁的add、remove操作,觸發數組的擴容或者縮容;
- 在正則表達式中,可以使用Pattern.compile()方法預編譯正則表達式,避免每次都創建新的Matcher對象;
- 儘量使用基本數據類型,避免使用包裝類,因為包裝類的創建和銷毀都會產生臨時對象;
- 儘量使用對象池的方式創建和管理對象,比如使用靜態工廠方法創建對象,避免使用new關鍵字創建對象,因為靜態工廠方法可以重用對象,避免創建新的臨時對象;
臨時對象的生命周期應該儘可能短,以便及時釋放記憶體資源。臨時對象的生命周期過長通常是由以下原因引起的:
- 對象未被正確地釋放:如果在方法執行完畢後,臨時對象沒有被正確地釋放,就會導致記憶體泄漏風險;
- 對象過度共用:如果臨時對象被過度共用,就可能會導致多個線程同時訪問同一個對象,從而導致線程安全問題和性能問題;
- 對象創建過於頻繁:如果在方法內部頻繁地創建臨時對象,就會導致記憶體開銷過大,可能會引起性能甚至記憶體溢出問題;
為避免臨時對象的生命周期過長,建議採取以下措施:
- 及時釋放對象:在方法執行完畢後,應該及時釋放臨時對象(比如主動將對象設置為null),以便回收記憶體資源;
- 避免過度共用:在多線程環境下,應該避免過度共用臨時對象,可以使用局部變數或ThreadLocal等方式來避免共用問題;
- 對象池技術:使用對象池技術可以避免頻繁創建臨時對象,從而降低記憶體開銷。對象池可以預先創建一定數量的對象,併在需要時從池中獲取對象,使用完畢後再將對象放回池中;
小結
正所謂:“不積跬步,無以至千里;不積小流,無以成江海”。以上列舉的編碼細節,都會直接或間接的影響服務的執行效率,只是影響多少的問題。現實中,有時候我們不必過於苛求,但它們有一個共同的註腳:極客精神。
三 設計優化
3.1 緩存
合理使用緩存可以有效提高應用程式的性能,縮短數據訪問時間,降低對數據源的依賴性。緩存可以進行多層級的設計,舉例,為了提高運行效率,CPU就設計了L1-L3三級緩存。在應用設計的時候,我們也可以按照業務訴求進行層設計。常見的分層設計有本地緩存(L1),遠程分散式緩存(L2)兩級。
本地緩存可以減少網路請求、節約計算資源、減少高負載數據源訪問等優勢,進而提高應用程式的響應速度和吞吐量。常見的本地緩存中間件有:Caffeine、Guava Cache、Ehcache。當然你也可以在使用類似Map容器,在應用程式中構建自己的緩存結構。 分散式緩存相比本地緩存的優勢是可以保證數據一致性、只保留一份數據,減少數據冗餘、可以實現數據分片,實現大容量數據的存儲。常見的分散式緩存有:Redis、Memcached。
實現一個簡單的LRU本地緩存示例如下:
/**
* Least recently used 記憶體緩存過期策略:最近最少使用
* Title: 帶容量的<b>線程不安全的</b>最近訪問排序的Hashmap
* Description: 最後訪問的元素在最後面。<br>
* 如果要線程安全,請使用<pre>Collections.synchronizedMap(new LRUHashMap(123));</pre> <br>
*
* @author: liuhuiqing
* @date: 20123/4/27
*/
public class LRUHashMap<K, V> extends LinkedHashMap<K, V> {
/**
* The Size.
*/
private final int maxSize;
/**
* 初始化一個最大值, 按訪問順序排序
*
* @param maxSize the max size
*/
public LRUHashMap(int maxSize) {
//0.75是預設值,true表示按訪問順序排序
super(maxSize, 0.75f, true);
this.maxSize = maxSize;
}
/**
* 初始化一個最大值, 按指定順序排序
*
* @param maxSize 最大值
* @param accessOrder true表示按訪問順序排序,false為插入順序
*/
public LRUHashMap(int maxSize, boolean accessOrder) {
//0.75是預設值,true表示按訪問順序排序,false為插入順序
super(maxSize, 0.75f, accessOrder);
this.maxSize = maxSize;
}
@Override
protected boolean removeEldestEntry(Map.Entry<K, V> eldest) {
return super.size() > maxSize;
}
}
3.2 非同步
非同步可以提高程式的性能和響應能力,使其能更高效地處理大規模數據或併發請求。其底層原理涉及到操作系統的多線程、事件迴圈、任務隊列以及回調函數等關鍵技術,除此之外,非同步的思想在應用架構設計方面也有廣泛的應用。常規的多線程,消息隊列,響應式編程等非同步處理方案這裡就不再展開介紹了,這裡介紹兩個大家可能容易忽視但實用技能:非阻塞IO和 協程。
非阻塞IO
Java Servlet 3.0規範中引入了非同步Servlet的概念,可以幫助開發者提高應用程式的性能和併發處理能力,其原理是非阻塞IO使用單線程同時處理多個請求,避免了線程切換和阻塞的開銷,特別是在讀取大文件或者進行複雜耗時計算場景時,可以避免阻塞其他請求的處理。Spring MVC框架中也提供了相應的非同步處理方案。
•使用Callable方式實現非同步處理
@GetMapping("/async/callable")
public WebAsyncTask<String> asyncCallable() {
Callable<String> callable = () -> {
// 執行非同步操作
return "非同步任務已完成";
};
return new WebAsyncTask<>(10000, callable);
}
•使用DeferredResult方式實現非同步處理
@GetMapping("/async/deferredresult")
public DeferredResult<String> asyncDeferredResult() {
DeferredResult<String> deferredResult = new DeferredResult<>(10000L);
// 非同步處理完成後設置結果
deferredResult.setResult("DeferredResult非同步任務已完成");
return deferredResult;
}
協程
我們知道線程的創建、銷毀都十分消耗系統資源,所以有了線程池,但這還不夠,因為線程的數量是有限的(千級別),線程會阻塞操作系統線程,無法儘可能的提高吞吐量。因為使用線程的成本很高,所以才會有了虛擬線程,它是用戶態線程,成本是相當低廉的,調度也完全由用戶進行控制(JDK 中的調度器),它同樣可以進行阻塞,但不用阻塞操作系統線程,充分提高了硬體利用率,高併發也上了一個量級。
很長一段時間,協程概念並非作為JVM內置的功能,而是通過第三方庫或框架實現的。目前比較常用的協程實現庫有Quasar、Kilim等。但在Java19版本中,引入了虛擬線程(Virtual Threads )的支持(處於Preview階段)。
虛擬線程是java.lang.Thread的一個實現,可以使用java.lang.Thread.Builder介面創建
Thread thread = Thread.ofVirtual()
.name("Virtual Threads")
.unstarted(runnable);
也可以通過一個線程工廠類進行創建:
ThreadFactory factory = Thread.ofVirtual().factory();
虛擬線程運行的載體必須是線程,同一個線程中可以運行多個虛擬線程實例。
3.3 並行
並行處理的思想在大數據,多任務,流水線處理,模型訓練等各個方面發揮著重要作用,包括前面介紹的非同步(多線程,協程,消息等),也是建立在並行的基礎上。在應用層面,典型的場景有:
- 分散式計算框架中的MapReduce就是採用一種分而治之的思想設計出來的,將複雜或計算量大的任務,切分成一個個小的任務,小任務分別在不同的線程或伺服器上並行的執行,最終再彙總每個小任務的結果。
- 邊緣計算(Edge Computing)是一種分散式計算範式,它將計算、存儲和網路服務的部分功能從雲數據中心延伸至離數據源更近的地方,即網路的邊緣。這種計算方式能夠實現低延遲、節省帶寬、提高數據安全性以及實時處理與分析等優勢。
在代碼實現方面,做好解耦設計,接下來就可以進行並行設計了,比如:
- 多個請求可以通過多線程並行處理,每個請求的不同處理階段;
- 如查詢階段,可以採用協程並行執行;
- 存儲階段,可以採用消息訂閱發佈的方式進行處理;
- 監控統計階段,就可以採用NIO非同步的方式進行指標數據文件的寫入;
- 請求/響應採用非阻塞IO模式;
3.4 池化
池化就是初始預設資源,降低每次獲取資源的消耗,如創建線程的開銷,獲取遠程連接的開銷等。典型的場景就是線程池,資料庫連接池,業務處理結果緩存池等。
以資料庫連接池為例,其本質是一個 socket 的連接。為每個請求打開和維護資料庫連接,尤其是動態資料庫驅動的應用程式的請求,既昂貴又浪費資源。為什麼這麼說呢?以MySQL資料庫建立連接(TCP協議)為例,建立連接總共分三步:
- 建立TCP連接,通過三次握手實現;
- 伺服器發送給客戶端「握手信息」 ,客戶端響應該握手消息;
- 客戶端「發送認證包」 ,用於用戶驗證,驗證成功後,伺服器返回OK響應,之後開始執行命令;
簡單粗略統計,完成一次資料庫連接,客戶端和伺服器之間需要至少往返7次,總計平均耗時大約在200ms左右,這對於很對C端服務來說,幾乎是不能接受的。
落實到代碼編寫層面,也可以藉助這一思想來優化我們的程式執行性能。
- 公用的數據可以全局只定義一份,比如使用枚舉,static修飾的容器對象等;
- 根據實際情況,提前設置List,Map等容器對象的初始化容量大小,防止後面的擴容,對性能的影響;
- 亨元設計模式的應用等;
3.5 預處理
一般需要池化的內容,都是需要預處理的,比如為了保證服務的穩定性,線程池和資料庫連接池等需要池化的內容在JVM容器啟動時,處理真正請求之前,對這些池化內容進行預處理,等到真正的業務處理請求過來時,可以正常的快速處理。除此之外,預處理還可以體現在系統架構層面。
- 為了提高響應性能,將部分業務數據提前預載入到記憶體中;
- 為了減輕CPU壓力,將計算邏輯提前執行,直接將計算後的結果數據保存下來,直接供調用方使用;
- 為了降低網路帶寬成本,將傳輸數據通過壓縮演算法進行壓縮處理,到了目標服務,在進行解壓,獲得原始數據;
- Myibatis為了提高SQL語句的安全性和執行效率,也引入了預處理的概念;
四 總結
性能優化是程式開發過程中繞不過去一個課題,本文聚焦代碼和設計兩個方面,從CPU硬體到JVM容器,從緩存設計到數據預處理,全面的展現了性能優化的實施方向和落地細節。闡述的過程沒有追求各個方向的面面俱到,但都給到了一些場景化案例,來輔助理解和思考,起到拋磚引玉的效果。
作者:京東零售 劉慧卿
內容來源:京東雲開發者社區