前言

Java 是企業(yè)級開發(fā)的支柱語言，廣泛應(yīng)用于微服務(wù)、分布式系統(tǒng)和高并發(fā)場景。根據(jù) 2024 年 Stack Overflow 開發(fā)者調(diào)研，Java 在后端開發(fā)中排名前三，特別是在電商、金融和大數(shù)據(jù)領(lǐng)域。然而，線上 Java 應(yīng)用常面臨內(nèi)存溢出、CPU 飆升、慢查詢、線程死鎖等故障，導致服務(wù)不可用或性能下降。本文基于 Java 21 深入剖析常見線上故障的排查方案，涵蓋問題定位、工具使用、解決方案及預(yù)防措施，結(jié)合電商訂單系統(tǒng)案例，展示如何實現(xiàn) 99.99% 可用性、10 萬 QPS、P99 延遲 <5ms。

一、背景與需求

1.1 線上故障的挑戰(zhàn)

Java 應(yīng)用在高并發(fā)場景（如日訂單 1 億，數(shù)據(jù)量 1TB）下面臨多重挑戰(zhàn)：

• 高可用：需保證 99.99% 可用性，宕機 ?? 分鐘/周。
• 高性能：查詢延遲 <5ms，QPS >10 萬。
• 復(fù)雜性：微服務(wù)架構(gòu)下，故障定位涉及多服務(wù)、數(shù)據(jù)庫和中間件。
• 動態(tài)性：流量突增、代碼缺陷、資源競爭引發(fā)故障。
• 成本：快速恢復(fù)降低損失，單故障成本需 <1000 美元。

典型場景：

• 電商：訂單查詢卡頓，支付失敗。
• 金融：交易系統(tǒng) CPU 100%，響應(yīng)超時。
• 日志：日志處理內(nèi)存溢出，服務(wù)重啟。

1.2 常見故障類型

1.3 目標

• 功能：快速定位和解決線上故障。
• 性能：恢復(fù)時間 <10 分鐘，QPS >10 萬，P99 延遲 <5ms。
• 場景：電商訂單系統(tǒng)，日訂單 1 億，數(shù)據(jù)量 1TB。
• 合規(guī)性：日志可追溯，滿足審計要求。

1.4 技術(shù)棧

二、故障排查流程

2.1 通用排查步驟

1. 現(xiàn)象確認：
   • 通過監(jiān)控（Prometheus/Grafana）確認問題：延遲、錯誤率、資源使用率。
   • 查看日志（Kibana）定位異常堆棧。
2. 環(huán)境檢查：
   • 確認服務(wù)版本、配置、流量變化。
   • 檢查依賴服務(wù)（數(shù)據(jù)庫、Redis、MQ）狀態(tài)。
3. 問題定位：
   • 使用診斷工具（Arthas、jstack、jmap）分析堆、線程、GC。
   • 關(guān)聯(lián)代碼和業(yè)務(wù)邏輯。
4. 臨時修復(fù)：
   • 限流、降級、重啟、回滾。
5. 根因分析：
   • 復(fù)盤日志、堆棧、監(jiān)控數(shù)據(jù)。
6. 長期優(yōu)化：
   • 代碼修復(fù)、配置優(yōu)化、架構(gòu)調(diào)整。

2.2 工具鏈

三、常見故障及排查方案

3.1 內(nèi)存溢出（OutOfMemoryError）

現(xiàn)象：服務(wù)崩潰，日志報 java.lang.OutOfMemoryError: Java heap space 或 Metaspace。
原因：

• 大對象分配（如大 List、數(shù)組）。
• 內(nèi)存泄漏（如未關(guān)閉資源、緩存未清理）。
• 堆/元空間配置過小。

排查步驟：

1. 確認類型：
   • 查看日志，區(qū)分 Java heap space、Metaspace 或 GC overhead limit。
2. 堆轉(zhuǎn)儲：

   jmap -dump:live,format=b,file=heap.bin <pid>
   

   使用 jhat 或 Eclipse MAT 分析：
   • 查找大對象（java.util.ArrayList、byte[]）。
   • 檢查引用鏈，定位泄漏點。
3. 監(jiān)控 GC：

   jstat -gc <pid> 1000
   

   觀察 Full GC 頻率和堆使用率。
4. 代碼檢查：
   • 確認集合是否無限增長（如 HashMap 未清理）。
   • 檢查資源關(guān)閉（如 InputStream 未 close）。

解決方案：

• 臨時：增加堆內(nèi)存（-Xmx），重啟服務(wù)。
• 長期：
  • 優(yōu)化代碼，清理無用對象。
  • 使用弱引用（WeakHashMap）。
  • 調(diào)整堆大小：

    java -Xms2g -Xmx4g -XX:+HeapDumpOnOutOfMemoryError -jar app.jar
    

示例代碼（修復(fù)內(nèi)存泄漏）：

```java
@Service
public class CacheService {
    private final Map<String, String> cache = new WeakHashMap<>();

    public void addToCache(String key, String value) {
        cache.put(key, value);
    }

    public String getFromCache(String key) {
        return cache.get(key);
    }
}

### 3.2 CPU 飆升
**現(xiàn)象**：CPU 使用率接近 100%，接口響應(yīng)慢，QPS 下降。
**原因**：
- 死循環(huán)或高復(fù)雜度算法。
- 頻繁 GC。
- 線程競爭（如鎖爭用）。

**排查步驟**：
1. **定位進程**：
   ```bash
   top -H -p <pid>

找到高 CPU 線程 ID。
2. 線程堆棧：

jstack <pid> > thread.dump

搜索線程 ID（轉(zhuǎn)為 16 進制），檢查堆棧：

• 死循環(huán)：方法重復(fù)調(diào)用。
• 鎖爭用：線程狀態(tài)為 BLOCKED。

3. 方法耗時：
   使用 Arthas：

   java -jar arthas-boot.jar
   trace com.example.Service method
   

   定位耗時方法。
4. GC 檢查：

   jstat -gcutil <pid> 1000
   

   若 Full GC 頻繁，調(diào)整 GC 參數(shù)。

解決方案：

• 臨時：限流，重啟服務(wù)。
• 長期：
  • 優(yōu)化算法，降低復(fù)雜度。
  • 使用并發(fā)工具（如 ConcurrentHashMap）。
  • 調(diào)整 GC（如 G1GC）：

    java -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -jar app.jar
    

示例代碼（優(yōu)化死循環(huán)）：

```java
@Service
public class OrderService {
    public void processOrders(List<Order> orders) {
        // 修復(fù)死循環(huán)
        for (Order order : orders) {
            if (order == null) continue;
            process(order);
        }
    }

    private void process(Order order) {
        // 業(yè)務(wù)邏輯
    }
}

3.3 慢查詢

現(xiàn)象：接口延遲 >100ms，日志顯示數(shù)據(jù)庫查詢耗時。
原因：

• 索引缺失。
• SQL 未優(yōu)化（如全表掃描）。
• 數(shù)據(jù)庫連接池不足。

排查步驟：

1. 日志分析：
   • 使用 Kibana 搜索慢查詢?nèi)罩尽?/li>
   • 定位耗時 SQL。
2. SQL 性能：
   • 執(zhí)行 EXPLAIN 分析 SQL：

     EXPLAIN SELECT * FROM orders WHERE created_at > '2025-01-01';
     

     檢查是否走索引。
3. 連接池：
   • 檢查 HikariCP 指標（Spring Boot Actuator）：

     curl http://localhost:8080/actuator/metrics/hikaricp.connections
     

   • 確認連接是否耗盡。
4. Arthas 跟蹤：

   trace org.springframework.jdbc.core.JdbcTemplate query
   

解決方案：

• 臨時：增加連接池大小，重啟。
• 長期：
  • 添加索引：

    CREATE INDEX idx_created_at ON orders(created_at);
    

  • 優(yōu)化 SQL，減少掃描行。
  • 配置連接池：

    ```yaml
    spring:
      datasource:
        hikari:
          maximum-pool-size: 50
          minimum-idle: 10
    

3.4 線程死鎖

現(xiàn)象：請求無響應(yīng)，線程數(shù)激增，日志無明顯異常。

原因：

• 多線程競爭鎖（如 synchronized）。
• 資源順序不一致。

排查步驟：

1. 線程堆棧：

   jstack <pid> > thread.dump
   

   搜索 deadlock，定位阻塞線程：

   Found 1 deadlock:
   Thread 1: waiting for lock A owned by Thread 2
   Thread 2: waiting for lock B owned by Thread 1
   

2. 代碼檢查：
   • 定位鎖對象，檢查 synchronized 或 ReentrantLock。
3. Arthas 分析：

   thread -b
   

   顯示阻塞線程和鎖信息。

解決方案：

• 臨時：重啟服務(wù)。
• 長期：
  • 統(tǒng)一鎖順序：

    ```java
    public class ResourceService {
        private final Object lockA = new Object();
        private final Object lockB = new Object();
    
        public void process() {
            synchronized (lockA) {
                synchronized (lockB) {
                    // 業(yè)務(wù)邏輯
                }
            }
        }
    }
    

  • 使用 ReentrantLock 超時機制。

3.5 GC 頻繁

現(xiàn)象：接口停頓，日志顯示 Full GC 頻繁，吞吐量下降。

原因：

• 堆內(nèi)存不足。
• 大對象頻繁分配。
• GC 算法不適合。

排查步驟：

1. GC 日志：
   • 啟用 GC 日志：

     java -XX:+PrintGCDetails -Xloggc:gc.log -jar app.jar
     

   • 分析 Full GC 頻率和停頓時間。
2. 堆使用：

   jmap -histo:live <pid>
   

   檢查大對象。
3. VisualVM：
   • 監(jiān)控 Eden、Old 區(qū)增長。

解決方案：

• 臨時：增加堆內(nèi)存。
• 長期：
  • 優(yōu)化對象分配：

    ```java
    public class DataService {
        public List<String> processData(List<String> input) {
            List<String> result = new ArrayList<>(input.size());
            // 避免動態(tài)擴容
            for (String item : input) {
                result.add(item.toUpperCase());
            }
            return result;
        }
    }
    

  • 使用 G1GC：

    java -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -jar app.jar
    

3.6 連接池耗盡

現(xiàn)象：日志報 SQLException: Connection timed out 或 Redis 連接失敗。

原因：

• 連接未釋放。
• 連接池配置不足。
• 依賴服務(wù)故障。

排查步驟：

1. 監(jiān)控指標：
   • 檢查 Actuator 連接池指標：

     curl http://localhost:8080/actuator/metrics/hikaricp.connections.active
     

2. 日志分析：
   • 搜索 Connection refused 或 Timeout。
3. Arthas 跟蹤：

   trace com.zaxxer.hikari.HikariDataSource getConnection
   

解決方案：

• 臨時：增加連接池，重啟。
• 長期：
  • 檢查資源釋放：

    ```java
    @Service
    public class DbService {
        @Autowired
        private JdbcTemplate jdbcTemplate;
    
        public void query() {
            try (Connection conn = jdbcTemplate.getDataSource().getConnection()) {
                // 查詢邏輯
            } catch (SQLException e) {
                log.error("Query failed", e);
            }
        }
    }
    

  • 優(yōu)化連接池配置：

    spring:
      datasource:
        hikari:
          maximum-pool-size: 100
          connection-timeout: 30000
    

四、案例實踐：電商訂單系統(tǒng)

4.1 背景

• 業(yè)務(wù)：訂單查詢、支付，需高可用和高性能。
• 規(guī)模：日訂單 1 億，數(shù)據(jù)量 1TB，QPS 10 萬。
• 環(huán)境：Java 21，Spring Boot，Kubernetes（100 節(jié)點）。
• 問題：
  • 內(nèi)存溢出導致服務(wù)崩潰。
  • CPU 100% 引發(fā)超時。
  • 慢查詢影響用戶體驗。
  • 死鎖導致支付失敗。

4.2 解決方案

4.2.1 內(nèi)存溢出

• 現(xiàn)象：OutOfMemoryError，服務(wù)宕機。
• 排查：使用 jmap 轉(zhuǎn)儲堆，MAT 分析發(fā)現(xiàn) HashMap 未清理。
• 修復(fù)：

  Map<String, Order> cache = new WeakHashMap<>();
  

• 結(jié)果：內(nèi)存占用從 4GB 降至 1.5GB。

4.2.2 CPU 飆升

• 現(xiàn)象：CPU 100%，QPS 降至 1 萬。
• 排查：jstack 發(fā)現(xiàn)死循環(huán)，Arthas 定位方法。
• 修復(fù)：

  for (Order order : orders) {
      if (order == null) continue;
      process(order);
  }
  

• 結(jié)果：QPS 恢復(fù)至 12 萬。

4.2.3 慢查詢

• 現(xiàn)象：訂單查詢 >500ms。
• 排查：EXPLAIN 發(fā)現(xiàn)無索引。
• 修復(fù)：

  CREATE INDEX idx_user_id ON orders(user_id);
  

• 結(jié)果：延遲從 500ms 降至 3ms。

4.2.4 死鎖

• 現(xiàn)象：支付接口無響應(yīng)。
• 排查：jstack 發(fā)現(xiàn)鎖競爭。
• 修復(fù)：

  synchronized (lockA) {
      synchronized (lockB) {
          // 統(tǒng)一鎖順序
      }
  }
  

• 結(jié)果：支付成功率 100%。

4.3 成果

• 性能：
  • P99 延遲：3ms（目標 <5ms）。
  • QPS：12 萬（目標 10 萬）。
• 可用性：
  • 99.99%（宕機 ?? 分鐘/周）。
• 恢復(fù)時間：
  • 平均 5 分鐘（目標 <10 分鐘）。
• 成本：
  • 單故障 <500 美元。

五、最佳實踐

5.1 監(jiān)控與告警

• Prometheus 配置：

  ```yaml
  scrape_configs:
    - job_name: 'java-app'
      metrics_path: '/actuator/prometheus'
      static_configs:
        - targets: ['localhost:8080']
  

• Grafana 儀表盤：監(jiān)控 CPU、內(nèi)存、延遲、GC。

5.2 日志管理

• ELK 配置：

  logging:
    file:
      name: /logs/app.log
    logstash:
      host: localhost
      port: 5044
  

5.3 JVM 參數(shù)

java -Xms2g -Xmx4g -XX:+UseG1GC -XX:MaxGCPauseMillis=100 \
     -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintGCDetails \
     -Xloggc:gc.log -jar app.jar

5.4 故障演練

• 使用 Chaos Mesh 模擬故障：

  apiVersion: chaos-mesh.org/v1alpha1
  kind: PodChaos
  metadata:
    name: pod-failure
  spec:
    selector:
      namespaces: ['default']
    mode: one
    action: pod-kill
  

5.5 代碼規(guī)范

• ESLint 類似工具：Checkstyle、PMD。
• 依賴管理：

  <dependency>
      <groupId>com.google.guava</groupId>
      <artifactId>guava</artifactId>
      <version>33.3.1-jre</version>
  </dependency>
  

六、常見問題與解決方案

1. 問題1：日志丟失：
   • 場景：Kibana 無異常日志。
   • 解決：增大 Logstash 緩沖區(qū)，異步日志。
2. 問題2：誤判故障：
   • 場景：流量突增誤以為 CPU 問題。
   • 解決：結(jié)合 Prometheus 指標確認。
3. 問題3：工具卡頓：
   • 場景：Arthas 響應(yīng)慢。
   • 解決：降低采樣率，優(yōu)化 JVM 參數(shù)。
4. 問題4：恢復(fù)慢：
   • 場景：重啟耗時 >10 分鐘。
   • 解決：預(yù)熱緩存，優(yōu)化啟動。

七、未來趨勢

1. Java 22+：虛擬線程降低線程開銷。
2. AI 輔助：自動定位根因，推薦修復(fù)。
3. 云原生：Serverless 架構(gòu)減少運維負擔。
4. eBPF：更細粒度的性能監(jiān)控。

八、總結(jié)

Java 線上故障排查需結(jié)合監(jiān)控（Prometheus）、診斷（Arthas、jstack）、日志（ELK）和代碼優(yōu)化。常見故障包括內(nèi)存溢出、CPU 飆升、慢查詢、死鎖、GC 頻繁和連接池耗盡，需系統(tǒng)化流程和工具鏈應(yīng)對。電商案例驗證了 P99 延遲 3ms、QPS 12 萬、恢復(fù)時間 5 分鐘的效果。最佳實踐包括：

• 監(jiān)控：Prometheus + Grafana。
• 診斷：Arthas + VisualVM。
• 優(yōu)化：JVM 參數(shù) + 代碼規(guī)范。
• 演練：Chaos Mesh 模擬故障。

故障排查是保障高可用性的關(guān)鍵，未來將在 AI 和云原生方向演進。

到此這篇關(guān)于Java常見線上故障的排查方案的文章就介紹到這了,更多相關(guān)Java常見線上故障排查內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！