統計接口耗時的6種常見方法

前言

今天，我想和大家聊聊一個看似簡單、卻在實際項目中經常被忽略的話題：統計接口耗時。

有些小伙伴在工作中，可能經常遇到這樣的場景：線上接口突然變慢，用戶抱怨連連，你卻一頭霧水，不知道問題出在哪里。

或者，在性能優化時，你費盡心思優化了代碼，卻無法量化優化效果。

其實，這些問題都離不開一個基礎技能——如何準確統計接口耗時。

今天，我就跟大家一起聊聊統計接口耗時的6種常見方法，希望對你會有所幫助。

為什么統計接口耗時如此重要？

在深入方法之前，我們先聊聊為什么接口耗時統計這么關鍵。

從架構師的角度看，這不僅僅是“記錄一個時間”那么簡單。

接口耗時直接反映了系統性能，它是：

性能優化的基石：沒有耗時數據，優化就像盲人摸象，你根本不知道瓶頸在哪里。
監控告警的源頭：通過耗時趨勢，你可以提前發現系統異常，比如慢SQL、資源競爭等問題。
用戶體驗的晴雨表：接口響應時間直接影響用戶滿意度，尤其在高并發場景下，幾毫秒的延遲都可能造成流失。

舉個例子，有些小伙伴在工作中，可能直接用System.currentTimeMillis()在方法開始和結束處打日志，覺得這很簡單。但如果你在多線程環境下這么做，可能會發現數據不準，因為系統時間可能被調整，或者日志輸出本身影響性能。

這就是為什么我們需要更專業的方法。

好了，廢話不多說，讓我們開始今天的主菜。我將從最簡單的原生Java方法，逐步深入到分布式系統中的高級工具，確保每種方法都講透、講懂。

方法一：System.currentTimeMillis()

這是最基礎、最直接的方法，估計每個Java程序員都用過。

它的原理很簡單：在方法開始時記錄當前時間，在結束時再記錄一次，然后計算差值。

為什么用這個方法？

對于一些簡單的場景，比如測試某個方法塊的執行時間，這種方法快速有效。

它不依賴任何第三方庫，純原生Java實現。

示例代碼

public class SimpleTimeTracker {
    public void processRequest() {
        long startTime = System.currentTimeMillis(); // 記錄開始時間
        
        // 模擬業務處理：假設這里是一些核心邏輯
        try {
            Thread.sleep(100); // 模擬耗時操作，如數據庫查詢或外部API調用
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        
        long endTime = System.currentTimeMillis(); // 記錄結束時間
        long duration = endTime - startTime; // 計算耗時
        
        System.out.println("接口耗時: " + duration + "ms");
    }
    
    public static void main(String[] args) {
        new SimpleTimeTracker().processRequest();
    }
}

代碼邏輯詳解

System.currentTimeMillis() 返回當前時間與1970年1月1日UTC時間的毫秒差。這是一個靜態方法，調用成本很低。
我們在方法入口處調用它，保存到startTime變量。
在方法出口處再次調用，保存到endTime變量。
耗時就是endTime - startTime，單位是毫秒。
最后，我們打印出耗時，或者可以記錄到日志系統中。

深度剖析

有些小伙伴在工作中可能覺得這方法太“土”，但它其實有幾個隱藏問題：

精度問題：System.currentTimeMillis() 的精度是毫秒，對于短時間操作（比如幾毫秒內的調用），可能無法準確測量。如果你需要更高精度，可以用System.nanoTime()，它返回納秒級時間，但注意它不表示實際時間，只適合計算相對時間差。
系統時間影響：如果系統時間在過程中被調整（比如NTP同步），currentTimeMillis可能回退或跳躍，導致計算出的耗時為負數或異常值。nanoTime不受此影響，因為它基于系統啟動時間。
代碼侵入性：你需要手動在每個方法中添加代碼，如果接口眾多，會顯得臃腫，且容易遺漏。

為了更直觀地理解這個過程，我畫了一個流程圖，展示了手動計時的基本流程：

適用場景

快速調試或本地測試。
簡單的單線程應用，不需要高精度。
作為學習其他方法的基礎。

盡管這種方法有局限，但它讓我們理解了核心思想：在關鍵點打點計時。

接下來，我們會看到如何用更優雅的方式實現類似功能。

方法二：System.nanoTime()

如果你對精度要求更高，比如需要統計微秒或納秒級的操作，System.nanoTime()是更好的選擇。

它專門用于測量時間間隔，而不是獲取實際時間。

為什么用這個方法？

在高性能場景下，比如算法優化或低延遲交易系統，毫秒級精度可能不夠。

nanoTime提供納秒級精度，且不受系統時間調整影響。

示例代碼

public class NanoTimeTracker {
    public void processRequest() {
        long startTime = System.nanoTime(); // 納秒級開始時間
        
        // 模擬業務處理
        try {
            Thread.sleep(100); // 注意：sleep單位是毫秒，實際業務可能是納秒級操作
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        
        long endTime = System.nanoTime(); // 納秒級結束時間
        long duration = (endTime - startTime) / 1_000_000; // 轉換為毫秒
        
        System.out.println("接口耗時: " + duration + "ms");
    }
    
    public static void main(String[] args) {
        new NanoTimeTracker().processRequest();
    }
}

代碼邏輯詳解

System.nanoTime() 返回一個納秒級的時間戳，但這個值只對計算相對時間差有意義。
我們同樣在開始和結束處調用，但計算出的duration單位是納秒。
為了方便閱讀，我們通常轉換為毫秒（除以1,000,000）。
注意：Thread.sleep(100)是毫秒單位，這里只是模擬；實際業務可能是CPU密集型操作，適合用納秒測量。

深度剖析

有些小伙伴在工作中可能混淆currentTimeMillis和nanoTime，關鍵區別在于：

用途不同：currentTimeMillis用于獲取實際時間（如日志時間戳），而nanoTime用于測量耗時。
精度和性能：nanoTime通常精度更高，但調用成本可能略高（取決于JVM實現）。在現代JVM中，這個差異可以忽略。
溢出問題：nanoTime的值可能溢出（雖然很少見），但因為是計算差值，只要時間間隔不超過292年（2^63納秒），就不會有問題。

我建議：如果需要高精度測量，就用nanoTime；如果只是大概記錄，用currentTimeMillis即可。

但這兩種方法都有代碼侵入性問題，接下來我們看看如何用AOP解決。

方法三：Spring AOP

Spring AOP（面向切面編程）是Java生態中解決橫切關注點（如日志、耗時統計）的利器。

它允許你在不修改業務代碼的情況下，動態添加功能。

為什么用這個方法？

作為架構師，我特別推崇AOP，因為它實現了“關注點分離”。

業務代碼只關心核心邏輯，而耗時統計這種通用功能由切面處理。

這樣代碼更干凈，也更易維護。

示例代碼

首先，確保你的項目依賴了Spring AOP（例如在Spring Boot中，通常已包含）。

// 定義一個注解，用于標記需要統計耗時的方法
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface TimeCost {
    String value() default "";
}

// 編寫切面類
@Aspect
@Component
public class TimeCostAspect {
    private static final Logger logger = LoggerFactory.getLogger(TimeCostAspect.class);
    
    // 定義切點：標注了@TimeCost注解的方法
    @Around("@annotation(timeCost)")
    public Object around(ProceedingJoinPoint joinPoint, TimeCost timeCost) throws Throwable {
        long startTime = System.currentTimeMillis();
        Object result = null;
        try {
            result = joinPoint.proceed(); // 執行目標方法
        } finally {
            long endTime = System.currentTimeMillis();
            long duration = endTime - startTime;
            logger.info("方法 {} 耗時: {}ms", joinPoint.getSignature().getName(), duration);
        }
        return result;
    }
}

// 在業務方法上使用注解
@Service
public class UserService {
    @TimeCost("獲取用戶信息")
    public User getUserById(Long id) {
        // 模擬業務邏輯
        try {
            Thread.sleep(50);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return new User(id, "用戶" + id);
    }
}

代碼邏輯詳解

注解定義：@TimeCost是一個自定義注解，用于標記需要統計耗時的方法。這樣，我們可以在任何方法上添加它，而無需修改方法內部代碼。
切面類：TimeCostAspect使用@Aspect和@Component注解，表示這是一個Spring管理的切面。
- @Around注解定義了環繞通知，它會在目標方法執行前后被調用。
- ProceedingJoinPoint參數代表被攔截的方法，proceed()方法用于執行原始方法。
- 我們在proceed()前后記錄時間，并計算耗時。
- 使用日志記錄耗時，避免控制臺輸出影響性能。
業務方法：在getUserById方法上添加@TimeCost，即可自動統計耗時。

深度剖析

有些小伙伴在工作中可能對AOP的底層原理感興趣。簡單來說，Spring AOP基于動態代理實現：

如果目標類實現了接口，Spring使用JDK動態代理。
如果沒實現接口，使用CGLIB字節碼增強。

這帶來了一個關鍵點：AOP只能攔截Spring管理的Bean方法，對于私有方法或非Bean對象無效。

此外，環繞通知的順序也可能影響行為，如果有多個切面，可以用@Order注解控制順序。

從性能角度看，AOP引入了一定的開銷（代理調用），但在大多數應用中可忽略。它的最大優勢是解耦，讓業務代碼保持純凈。

為了展示AOP的工作流程，我畫了一個序列圖：

適用場景

Spring項目，需要無侵入統計。
多個方法需要統一處理耗時邏輯。
團隊協作時，避免業務代碼被“污染”。

AOP雖然強大，但依賴于Spring框架。

如果你在用其他Web框架，或者需要更底層的控制，可以試試攔截器。

方法四：使用攔截器（Interceptor）

在Web應用中，攔截器是另一種常見的AOP實現方式，專門用于處理HTTP請求。

Spring MVC提供了HandlerInterceptor，可以攔截Controller方法的執行。

為什么用這個方法？

攔截器針對Web請求優化，它可以獲取HTTP上下文信息（如請求參數、響應狀態），非常適合統計接口級耗時。

相比AOP，它更輕量，且與Web層緊密集成。

示例代碼

// 自定義攔截器
@Component
public class TimeCostInterceptor implements HandlerInterceptor {
    private static final Logger logger = LoggerFactory.getLogger(TimeCostInterceptor.class);
    private static final String START_TIME_ATTRIBUTE = "startTime";
    
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        long startTime = System.currentTimeMillis();
        request.setAttribute(START_TIME_ATTRIBUTE, startTime); // 將開始時間存入請求屬性
        return true; // 繼續執行鏈
    }
    
    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
        long startTime = (Long) request.getAttribute(START_TIME_ATTRIBUTE);
        long endTime = System.currentTimeMillis();
        long duration = endTime - startTime;
        logger.info("接口 {} 耗時: {}ms, 狀態碼: {}", request.getRequestURI(), duration, response.getStatus());
    }
}

// 注冊攔截器到Spring MVC
@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Autowired
    private TimeCostInterceptor timeCostInterceptor;
    
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(timeCostInterceptor).addPathPatterns("/**"); // 攔截所有路徑
    }
}

代碼邏輯詳解

攔截器類：實現HandlerInterceptor接口，重寫preHandle和afterCompletion方法。
- preHandle在Controller方法執行前調用，我們在這里記錄開始時間，并存入請求屬性（HttpServletRequest），以便后續使用。
- afterCompletion在請求完成后調用（包括視圖渲染后），我們在這里取出開始時間，計算總耗時。
- 注意：afterCompletion即使請求拋出異常也會調用，這確保了耗時統計的完整性。
注冊攔截器：通過WebMvcConfigurer的addInterceptors方法，將攔截器注冊到Spring MVC中，并指定攔截路徑（這里是所有路徑）。

深度剖析

有些小伙伴在工作中可能問：攔截器和AOP有什么區別？

粒度不同：攔截器針對Web請求，可以獲取HTTP信息；AOP更通用，可以攔截任何Spring Bean方法。
執行時機：攔截器的preHandle在Controller前，afterCompletion在視圖渲染后；而AOP環繞通知只在方法執行前后。
性能：攔截器通常比AOP輕量，因為它專為Web優化。

一個常見陷阱是：攔截器統計的耗時包括視圖渲染時間，而AOP只統計方法執行時間。

如果你只關心業務邏輯耗時，可能AOP更合適；如果需要全鏈路耗時（包括HTTP層），攔截器更好。

從架構角度，攔截器適合Web API的監控，而AOP適合業務方法監控。

它們可以結合使用，覆蓋不同層次。

方法五：過濾器（Servlet Filter）

過濾器是Servlet規范的一部分，它在請求進入Servlet容器的最早階段被調用，可以統計從接收到請求到返回響應的完整時間。

為什么用這個方法？

過濾器比攔截器更“底層”，它可以攔截所有請求（包括靜態資源），且不依賴Spring框架。

如果你在用純Servlet應用，或者需要統計整個請求生命周期，過濾器是理想選擇。

示例代碼

// 自定義過濾器
@Component
@Order(1) // 指定執行順序，數字越小優先級越高
public class TimeCostFilter implements Filter {
    private static final Logger logger = LoggerFactory.getLogger(TimeCostFilter.class);
    
    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        long startTime = System.currentTimeMillis();
        try {
            chain.doFilter(request, response); // 繼續執行過濾器鏈
        } finally {
            long endTime = System.currentTimeMillis();
            long duration = endTime - startTime;
            HttpServletRequest httpRequest = (HttpServletRequest) request;
            HttpServletResponse httpResponse = (HttpServletResponse) response;
            logger.info("過濾器統計 - 接口 {} 耗時: {}ms, 狀態碼: {}", httpRequest.getRequestURI(), duration, httpResponse.getStatus());
        }
    }
}
// 注意：在Spring Boot中，@Component會自動注冊過濾器；非Spring項目需在web.xml配置

代碼邏輯詳解

實現Filter接口，重寫doFilter方法。
在doFilter開始時記錄時間，然后調用chain.doFilter()將請求傳遞給下一個過濾器或Servlet。
在finally塊中計算耗時，確保即使拋出異常也能記錄。
將ServletRequest和ServletResponse轉換為HTTP類型，以獲取URI和狀態碼。
@Order(1)指定過濾器執行順序，如果有多個過濾器，順序很重要。

深度剖析

過濾器的關鍵特點是它在整個請求處理鏈的最外層。這意味著它統計的時間包括：

過濾器鏈執行時間。
攔截器執行時間。
Controller方法執行時間。
視圖渲染時間。

有些小伙伴在工作中可能發現過濾器耗時比攔截器長，原因就在于此。

此外，過濾器是Servlet標準，兼容任何Java Web容器（如Tomcat、Jetty），而攔截器是Spring特有。

從性能視角，過濾器非常高效，因為它直接嵌入Servlet容器。

但要注意，如果過濾器鏈過長，可能成為瓶頸。建議將耗時統計過濾器放在鏈首，以獲取最準確的全鏈路時間。

為了對比過濾器、攔截器和AOP的范圍，我畫了一個層次圖：

這個圖清晰展示了三者的執行順序和范圍：過濾器最外層，攔截器在Spring MVC層，AOP在業務方法層。

方法六：Micrometer和APM工具

前面五種方法適合開發和測試環境，但在生產環境中，我們通常需要更強大的工具：比如Micrometer（指標收集庫）或APM（應用性能管理）工具如SkyWalking。

這些工具提供分布式追蹤、聚合統計和可視化功能。

為什么用這個方法？

我強烈推薦在生產環境使用專業工具。

因為它們：

低開銷：針對生產環境優化，采集開銷可控。
分布式支持：在微服務架構下，能追蹤跨服務調用鏈。
豐富功能：提供百分位數、均值、峰值等統計，并與告警系統集成。

示例代碼：使用Micrometer

Micrometer是一個指標門面庫，可以對接多種監控系統（如Prometheus、Datadog）。這里以Spring Boot Actuator為例。

首先，添加依賴（在pom.xml）：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-core</artifactId>
</dependency>
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

然后，配置自動統計：

// 無需額外代碼，Spring Boot自動集成Micrometer，通過Actuator端點暴露指標
// 在application.properties中啟用Prometheus端點
management.endpoints.web.exposure.include=prometheus,metrics

手動定制統計：

@Service
public class OrderService {
    private final MeterRegistry meterRegistry;
    private final Timer orderProcessTimer;
    
    public OrderService(MeterRegistry meterRegistry) {
        this.meterRegistry = meterRegistry;
        this.orderProcessTimer = Timer.builder("order.process.time")
            .description("訂單處理耗時")
            .register(meterRegistry);
    }
    
    public void processOrder(Order order) {
        orderProcessTimer.record(() -> {
            // 業務邏輯
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });
    }
}

代碼邏輯詳解

自動統計：Spring Boot Actuator自動為Web請求生成指標（如http.server.requests），包括耗時、狀態碼等。
手動定制：我們注入MeterRegistry，創建一個Timer指標，用于測量特定方法耗時。
- Timer.record()方法接受一個Runnable或Callable，自動記錄執行時間。
- 指標數據可以通過/actuator/prometheus端點暴露，供Prometheus采集。

深度剖析

有些小伙伴在工作中可能覺得Micrometer配置復雜，但它的優勢在于標準化。

你只需寫一次代碼，就能對接多種監控后端。

對于更復雜的場景，APM工具如SkyWalking是更好的選擇。

它們通過字節碼增強（無需修改代碼）自動采集數據，并提供全鏈路追蹤。

例如，在SkyWalking中，你只需添加Java Agent，就能在UI上看到接口耗時拓撲圖。

我建議：

中小項目：用Micrometer + Prometheus + Grafana，成本低，功能強大。
大型分布式系統：用APM工具如SkyWalking或Pinpoint，它們提供更細致的鏈路分析。

無論用哪種，核心思想是將耗時數據收集到中央系統，進行聚合和告警，而不是分散在日志中。

總結

經過以上6種方法的詳細剖析，相信你對統計接口耗時有了更深入的理解。

下面是我的一些實用建議：

方法對比表：

方法	優點	缺點	適用場景
System.currentTimeMillis()	簡單、無需依賴	精度低、代碼侵入	本地測試、簡單調試
System.nanoTime()	精度高	代碼侵入、需轉換單位	高性能測量、算法優化
Spring AOP	無侵入、解耦	僅Spring Bean、有代理開銷	業務方法監控、Spring項目
攔截器	Web優化、獲取HTTP上下文	僅Web請求、包括視圖時間	Web API監控
過濾器	底層、全鏈路	包括所有過濾器時間	全請求生命周期統計
Micrometer/APM	生產級、分布式支持	配置復雜、需基礎設施	生產環境、微服務架構

選擇原則：
- 開發/測試環境：可以用AOP或攔截器，快速驗證。
- 生產環境：務必使用Micrometer或APM工具，實現系統化監控。
- 精度要求：高精度用nanoTime，一般用毫秒即可。
- 代碼維護：優先無侵入方案（AOP/攔截器），保持代碼整潔。
最佳實踐：
- 不要過度統計：只關注關鍵接口，避免性能開銷。
- 結合日志和指標：耗時數據應同時記錄到日志（用于調試）和指標系統（用于監控）。
- 設置基線告警：基于歷史數據設置耗時閾值，自動觸發告警。

有些小伙伴在工作中，可能一開始覺得這些方法很復雜，但一旦掌握，就能在性能優化和故障排查中游刃有余。

記住，統計接口耗時不是目的，而是手段，最終目標是為用戶提供穩定、快速的服務。

最后說一句(求關注，別白嫖我)

如果這篇文章對您有所幫助，或者有所啟發的話，幫忙關注一下我的同名公眾號：蘇三說技術，您的支持是我堅持寫作最大的動力。

求一鍵三連：點贊、轉發、在看。

關注公眾號：【蘇三說技術】，在公眾號中回復：進大廠，可以免費獲取我最近整理的10萬字的面試寶典，好多小伙伴靠這個寶典拿到了多家大廠的offer。

更多項目實戰在我的技術網站：http://www.susan.net.cn/project

posted @ 2025-10-30 17:34 蘇三說技術閱讀(481) 評論(0) 收藏舉報

刷新頁面返回頂部

微信搜：蘇三說技術

關注公眾號：【蘇三說技術】，回復：進大廠，免費領取10萬字面試寶典。

統計接口耗時的6種常見方法

前言

為什么統計接口耗時如此重要？

方法一：System.currentTimeMillis()

為什么用這個方法？

示例代碼

代碼邏輯詳解

深度剖析

適用場景

方法二：System.nanoTime()

為什么用這個方法？

示例代碼

代碼邏輯詳解

深度剖析

方法三：Spring AOP

為什么用這個方法？

示例代碼

代碼邏輯詳解

深度剖析

適用場景

方法四：使用攔截器（Interceptor）

為什么用這個方法？

示例代碼

代碼邏輯詳解

深度剖析

方法五：過濾器（Servlet Filter）

為什么用這個方法？

示例代碼

代碼邏輯詳解

深度剖析

方法六：Micrometer和APM工具

為什么用這個方法？

示例代碼：使用Micrometer

代碼邏輯詳解

深度剖析

總結

最后說一句(求關注，別白嫖我)

公告