資訊專欄INFORMATION COLUMN
摘要：常見標高線程上下文切換頻繁線程太多鎖競爭激烈標高如果的占用很高，排查涉及到的程序，比如把改造成。抖動問題原因字節碼轉為機器碼需要占用時間片，大量的在執行字節碼時，導致長期處于高位現象，占用率最高解決辦法保證編譯線程的占比。
一、并發
Unable to create new native thread ……
問題1：Java中創建一個線程消耗多少內存？
每個線程有獨自的棧內存，共享堆內存
問題2：一臺機器可以創建多少線程？
CPU，內存，操作系統，JVM，應用服務器
我們編寫一段示例代碼，來驗證下線程池與非線程池的區別：
//線程池和非線程池的區別
public class ThreadPool {
public static int times = 100;//100,1000,10000
public static ArrayBlockingQueue arrayWorkQueue = new ArrayBlockingQueue(1000);
public static ExecutorService threadPool = new ThreadPoolExecutor(5, //corePoolSize線程池中核心線程數
10,
60,
TimeUnit.SECONDS,
arrayWorkQueue,
new ThreadPoolExecutor.DiscardOldestPolicy()
);
public static void useThreadPool() {
Long start = System.currentTimeMillis();
for (int i = 0; i < times; i++) {
threadPool.execute(new Runnable() {
public void run() {
System.out.println("說點什么吧...");
}
});
}
threadPool.shutdown();
while (true) {
if (threadPool.isTerminated()) {
Long end = System.currentTimeMillis();
System.out.println(end - start);
break;
}
}
}
public static void createNewThread() {
Long start = System.currentTimeMillis();
for (int i = 0; i < times; i++) {
new Thread() {
public void run() {
System.out.println("說點什么吧...");
}
}.start();
}
Long end = System.currentTimeMillis();
System.out.println(end - start);
}
public static void main(String args[]) {
createNewThread();
//useThreadPool();
}
}
啟動不同數量的線程，然后比較線程池和非線程池的執行結果：
| 非線程池 | 線程池 | |
|---|---|---|
| 100次 | 16毫秒 | 5ms的 |
| 1000次 | 90毫秒 | 28ms |
| 10000次 | 1329ms | 164ms |
結論：不要new Thread()，采用線程池
非線程池的缺點：
每次創建性能消耗大
無序，缺乏管理。容易無限制創建線程，引起OOM和死機
1.1 使用線程池要注意的問題避免死鎖，請盡量使用CAS
我們編寫一個樂觀鎖的實現示例：
public class CASLock {
public static int money = 2000;
public static boolean add2(int oldm, int newm) {
try {
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
if (money == oldm) {
money = money + newm;
return true;
}
return false;
}
public synchronized static void add1(int newm) {
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
money = money + newm;
}
public static void add(int newm) {
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
money = money + newm;
}
public static void main(String args[]) {
Thread one = new Thread() {
public void run() {
//add(5000)
while (true) {
if (add2(money, 5000)) {
break;
}
}
}
};
Thread two = new Thread() {
public void run() {
//add(7000)
while (true) {
if (add2(money, 7000)) {
break;
}
}
}
};
one.start();
two.start();
try {
one.join();
two.join();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println(money);
}
}
使用ThreadLocal要注意
ThreadLocalMap使用ThreadLocal的弱引用作為key，如果一個ThreadLocal沒有外部強引用來引用它，那么系統 GC 的時候，這個ThreadLocal勢必會被回收，這樣一來，ThreadLocalMap中就會出現key為null的Entry，就沒有辦法訪問這些key為null的Entry的value，如果當前線程再遲遲不結束的話，這些key為null的Entry的value就會一直存在一條強引用鏈：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永遠無法回收，造成內存泄漏。
我們編寫一個ThreadLocalMap正確使用的示例：
//ThreadLocal應用實例
public class ThreadLocalApp {
public static final ThreadLocal threadLocal = new ThreadLocal();
public static void muti2() {
int i[] = (int[]) threadLocal.get();
i[1] = i[0] * 2;
threadLocal.set(i);
}
public static void muti3() {
int i[] = (int[]) threadLocal.get();
i[2] = i[1] * 3;
threadLocal.set(i);
}
public static void muti5() {
int i[] = (int[]) threadLocal.get();
i[3] = i[2] * 5;
threadLocal.set(i);
}
public static void main(String args[]) {
for (int i = 0; i < 5; i++) {
new Thread() {
public void run() {
int start = new Random().nextInt(10);
int end[] = {0, 0, 0, 0};
end[0] = start;
threadLocal.set(end);
ThreadLocalApp.muti2();
ThreadLocalApp.muti3();
ThreadLocalApp.muti5();
//int end = (int) threadLocal.get();
System.out.println(end[0] + " " + end[1] + " " + end[2] + " " + end[3]);
threadLocal.remove();
}
}.start();
}
}
}
1.2 線程交互—線程不安全造成的問題
經典的HashMap死循環造成CPU100%問題
我們模擬一個HashMap死循環的示例：
//HashMap死循環示例
public class HashMapDeadLoop {
private HashMap hash = new HashMap();
public HashMapDeadLoop() {
Thread t1 = new Thread() {
public void run() {
for (int i = 0; i < 100000; i++) {
hash.put(new Integer(i), i);
}
System.out.println("t1 over");
}
};
Thread t2 = new Thread() {
public void run() {
for (int i = 0; i < 100000; i++) {
hash.put(new Integer(i), i);
}
System.out.println("t2 over");
}
};
t1.start();
t2.start();
}
public static void main(String[] args) {
for (int i = 0; i < 1000; i++) {
new HashMapDeadLoop();
}
System.out.println("end");
}
}
https://coolshell.cn/articles/9606.html
HashMap死循環發生后，我們可以在線程棧中觀測到如下信息：
/HashMap死循環產生的線程棧
Thread-281" #291 prio=5 os_prio=31 tid=0x00007f9f5f8de000 nid=0x5a37 runnable [0x0000700006349000]
java.lang.Thread.State: RUNNABLE
at java.util.HashMap$TreeNode.split(HashMap.java:2134)
at java.util.HashMap.resize(HashMap.java:713)
at java.util.HashMap.putVal(HashMap.java:662)
at java.util.HashMap.put(HashMap.java:611)
at com.example.demo.HashMapDeadLoop$2.run(HashMapDeadLoop.java:26)
應用停滯的死鎖，Spring3.1的deadlock 問題
我們模擬一個死鎖的示例：
//死鎖的示例
public class DeadLock {
public static Integer i1 = 2000;
public static Integer i2 = 3000;
public static synchronized Integer getI2() {
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
return i2;
}
public static void main(String args[]) {
Thread one = new Thread() {
public void run() {
synchronized (i1) {
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (i2) {
System.out.println(i1 + i2);
}
}
}
};
one.start();
Thread two = new Thread() {
public void run() {
synchronized (i2) {
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (i1) {
System.out.println(i1 + i2);
}
}
}
};
two.start();
}
}
死鎖發生后，我們可以在線程棧中觀測到如下信息：
//死鎖時產生堆棧
"Thread-1":
at com.example.demo.DeadLock$2.run(DeadLock.java:47)
- waiting to lock (a java.lang.Integer)
- locked (a java.lang.Integer)
"Thread-0":
at com.example.demo.DeadLock$1.run(DeadLock.java:31)
- waiting to lock (a java.lang.Integer)
- locked (a java.lang.Integer)
Found 1 deadlock.
1.3 基于JUC的優化示例
一個計數器的優化，我們分別用Synchronized，ReentrantLock，Atomic三種不同的方式來實現一個計數器，體會其中的性能差異
//示例代碼
public class SynchronizedTest {
public static int threadNum = 100;
public static int loopTimes = 10000000;
public static void userSyn() {
//線程數
Syn syn = new Syn();
Thread[] threads = new Thread[threadNum];
//記錄運行時間
long l = System.currentTimeMillis();
for (int i = 0; i < threadNum; i++) {
threads[i] = new Thread(new Runnable() {
@Override
public void run() {
for (int j = 0; j < loopTimes; j++) {
//syn.increaseLock();
syn.increase();
}
}
});
threads[i].start();
}
//等待所有線程結束
try {
for (int i = 0; i < threadNum; i++)
threads[i].join();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("userSyn" + "-" + syn + " : " + (System.currentTimeMillis() - l) + "ms");
}
public static void useRea() {
//線程數
Syn syn = new Syn();
Thread[] threads = new Thread[threadNum];
//記錄運行時間
long l = System.currentTimeMillis();
for (int i = 0; i < threadNum; i++) {
threads[i] = new Thread(new Runnable() {
@Override
public void run() {
for (int j = 0; j < loopTimes; j++) {
syn.increaseLock();
//syn.increase();
}
}
});
threads[i].start();
}
//等待所有線程結束
try {
for (int i = 0; i < threadNum; i++)
threads[i].join();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("userRea" + "-" + syn + " : " + (System.currentTimeMillis() - l) + "ms");
}
public static void useAto() {
//線程數
Thread[] threads = new Thread[threadNum];
//記錄運行時間
long l = System.currentTimeMillis();
for (int i = 0; i < threadNum; i++) {
threads[i] = new Thread(new Runnable() {
@Override
public void run() {
for (int j = 0; j < loopTimes; j++) {
Syn.ai.incrementAndGet();
}
}
});
threads[i].start();
}
//等待所有線程結束
try {
for (int i = 0; i < threadNum; i++)
threads[i].join();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("userAto" + "-" + Syn.ai + " : " + (System.currentTimeMillis() - l) + "ms");
}
public static void main(String[] args) {
SynchronizedTest.userSyn();
SynchronizedTest.useRea();
SynchronizedTest.useAto();
}
}
class Syn {
private int count = 0;
public final static AtomicInteger ai = new AtomicInteger(0);
private Lock lock = new ReentrantLock();
public synchronized void increase() {
count++;
}
public void increaseLock() {
lock.lock();
count++;
lock.unlock();
}
@Override
public String toString() {
return String.valueOf(count);
}
}
結論，在并發量高，循環次數多的情況，可重入鎖的效率高于Synchronized，但最終Atomic性能最好。
二、通信 2.1 數據庫連接池的高效問題一定要在finally中close連接
一定要在finally中release連接
2.2 OIO/NIO/AIO| OIO | NIO | AIO | |
|---|---|---|---|
| 類型 | 阻塞 | 非阻塞 | 非阻塞 |
| 使用難度 | 簡單 | 復雜 | 復雜 |
| 可靠性 | 差 | 高 | 高 |
| 吞吐量 | 低 | 高 | 高 |
結論：我性能有嚴苛要求下，盡量應該采用NIO的方式進行通信。
2.3 TIME_WAIT(client)，CLOSE_WAIT(server)問題反應：經常性的請求失敗
獲取連接情況 netstat -n | awk "/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}"
TIME_WAIT：表示主動關閉，優化系統內核參數可。
CLOSE_WAIT：表示被動關閉。
ESTABLISHED：表示正在通信
解決方案：二階段完成后強制關閉
2.4 串行連接，持久連接（長連接），管道化連接結論：
管道連接的性能最優異，持久化是在串行連接的基礎上減少了打開/關閉連接的時間。
管道化連接使用限制：
1、HTTP客戶端無法確認持久化（一般是服務器到服務器，非終端使用）；
2、響應信息順序必須與請求信息順序一致；
3、必須支持冪等操作才可以使用管道化連接.
三、數據庫操作必須要有索引（特別注意按時間查詢）
單條操作or批量操作
注：很多程序員在寫代碼的時候隨意采用了單條操作的方式，但在性能要求前提下，要求采用批量操作方式。
四、JVM 4.1 CPU標高的一般處理步驟top查找出哪個進程消耗的cpu高
top –H –p查找出哪個線程消耗的cpu高
記錄消耗cpu最高的幾個線程
printf %x 進行pid的進制轉換
jstack記錄進程的堆棧信息
找出消耗cpu最高的線程信息
4.2 內存標高（OOM）一般處理步驟jstat命令查看FGC發生的次數和消耗的時間，次數越多，耗時越長說明存在問題；
連續查看jmap –heap 查看老生代的占用情況，變化越大說明程序存在問題；
使用連續的jmap –histo:live 命令導出文件，比對加載對象的差異，差異部分一般是發生問題的地方。
4.3 GC引起的單核標高單個CPU占用率高，首先從GC查起。
4.4 常見SY標高線程上下文切換頻繁
線程太多
鎖競爭激烈
4.5 Iowait標高如果IO的CPU占用很高，排查涉及到IO的程序，比如把OIO改造成NIO。
4.6 抖動問題原因：字節碼轉為機器碼需要占用CPU時間片，大量的CPU在執行字節碼時，導致CPU長期處于高位；
現象：“C2 CompilerThread1” daemon，“C2 CompilerThread0” daemon CPU占用率最高；
解決辦法：保證編譯線程的CPU占比。
作者：梁鑫
來源：宜信技術學院
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/74508.html
摘要：運行時數據區域的學習，是學習以及機制的基礎，也是深入理解對象創建及運行過程的前提。了解內存區域劃分，是學習概念的前提。 Java 運行時數據區域的學習，是學習 jvm 以及 GC 機制的基礎，也是深入理解 java 對象創建及運行過程的前提。廢話不多說，直接進入正題： 一張圖總結 showImg(https://segmentfault.com/img/bVOMAn?w=685&h=5...
摘要：模塊系統的前身是項目。最初，該項目僅僅是為設計實現一個模塊系統。隨著項目的不斷深入，平臺對標準模塊系統的呼求也日益增長，批準該項目升級為平臺的一部分，也能服務于和平臺的需求。自定義的配置，僅包含一組指定的模塊及其所需的模塊。 我的博客 轉載請注明原創出處。 序 從Java 9開始，在Java的世界里多了一個叫模塊（JSR376）的特性。模塊系統的前身是Jigsaw項目。最初，該項目僅...
摘要：限制編寫并行流，存在一些與非并行流不一樣的約定。底層框架并行流在底層沿用的框架，遞歸式的分解問題，然后每段并行執行，最終由合并結果，返回最后的值。 本書第六章的讀書筆記，也是我這個系列的最后一篇讀書筆記。后面7、8、9章分別講的測試、調試與重構、設計和架構的原則以及使用Lambda表達式編寫并發程序，因為筆記不好整理，就不寫了，感興趣的同學自己買書來看吧。 并行化流操作 關于并行與并發...
摘要：探討判斷橫豎屏的最佳實現前端掘金在移動端，判斷橫豎屏的場景并不少見，比如根據橫豎屏以不同的樣式來適配，抑或是提醒用戶切換為豎屏以保持良好的用戶體驗。 探討判斷橫豎屏的最佳實現 - 前端 - 掘金在移動端，判斷橫豎屏的場景并不少見，比如根據橫豎屏以不同的樣式來適配，抑或是提醒用戶切換為豎屏以保持良好的用戶體驗。 判斷橫豎屏的實現方法多種多樣，本文就此來探討下目前有哪些實現方法以及其中的優...
閱讀 711·2021-11-16 11:44
閱讀 3541·2019-08-26 12:13
閱讀 3236·2019-08-26 10:46
閱讀 2352·2019-08-23 12:37
閱讀 1180·2019-08-22 18:30
閱讀 2526·2019-08-22 17:30
閱讀 1835·2019-08-22 17:26
閱讀 2284·2019-08-22 16:20
