前言

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

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

或者，在性能優(yōu)化時，你費(fèi)盡心思優(yōu)化了代碼，卻無法量化優(yōu)化效果。

其實(shí)，這些問題都離不開一個基礎(chǔ)技能——如何準(zhǔn)確統(tǒng)計接口耗時。

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

為什么統(tǒng)計接口耗時如此重要？

在深入方法之前，我們先聊聊為什么接口耗時統(tǒng)計這么關(guān)鍵。

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

接口耗時直接反映了系統(tǒng)性能，它是：

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

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

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

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

方法一：System.currentTimeMillis()

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

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

為什么用這個方法？

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

它不依賴任何第三方庫，純原生Java實(shí)現(xiàn)。

示例代碼

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

代碼邏輯詳解

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

深度剖析

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

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

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

適用場景

• 快速調(diào)試或本地測試。
• 簡單的單線程應(yīng)用，不需要高精度。
• 作為學(xué)習(xí)其他方法的基礎(chǔ)。

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

接下來，我們會看到如何用更優(yōu)雅的方式實(shí)現(xiàn)類似功能。

方法二：System.nanoTime()

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

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

為什么用這個方法？

在高性能場景下，比如算法優(yōu)化或低延遲交易系統(tǒng)，毫秒級精度可能不夠。

nanoTime提供納秒級精度，且不受系統(tǒng)時間調(diào)整影響。

示例代碼

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

代碼邏輯詳解

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

深度剖析

有些小伙伴在工作中可能混淆currentTimeMillis和nanoTime，關(guān)鍵區(qū)別在于：

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

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

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

方法三：Spring AOP

Spring AOP（面向切面編程）是Java生態(tài)中解決橫切關(guān)注點(diǎn)（如日志、耗時統(tǒng)計）的利器。

它允許你在不修改業(yè)務(wù)代碼的情況下，動態(tài)添加功能。

為什么用這個方法？

作為架構(gòu)師，我特別推崇AOP，因為它實(shí)現(xiàn)了“關(guān)注點(diǎn)分離”。

業(yè)務(wù)代碼只關(guān)心核心邏輯，而耗時統(tǒng)計這種通用功能由切面處理。

這樣代碼更干凈，也更易維護(hù)。

示例代碼

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

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

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

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

代碼邏輯詳解

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

深度剖析

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

• 如果目標(biāo)類實(shí)現(xiàn)了接口，Spring使用JDK動態(tài)代理。
• 如果沒實(shí)現(xiàn)接口，使用CGLIB字節(jié)碼增強(qiáng)。

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

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

從性能角度看，AOP引入了一定的開銷（代理調(diào)用），但在大多數(shù)應(yīng)用中可忽略。它的最大優(yōu)勢是解耦，讓業(yè)務(wù)代碼保持純凈。

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

適用場景

• Spring項目，需要無侵入統(tǒng)計。
• 多個方法需要統(tǒng)一處理耗時邏輯。
• 團(tuán)隊協(xié)作時，避免業(yè)務(wù)代碼被“污染”。

AOP雖然強(qiáng)大，但依賴于Spring框架。

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

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

在Web應(yīng)用中，攔截器是另一種常見的AOP實(shí)現(xiàn)方式，專門用于處理HTTP請求。

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

為什么用這個方法？

攔截器針對Web請求優(yōu)化，它可以獲取HTTP上下文信息（如請求參數(shù)、響應(yīng)狀態(tài)），非常適合統(tǒng)計接口級耗時。

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

示例代碼

// 自定義攔截器
@Component
publicclass TimeCostInterceptor implements HandlerInterceptor {
    privatestaticfinal Logger logger = LoggerFactory.getLogger(TimeCostInterceptor.class);
    privatestaticfinal 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); // 將開始時間存入請求屬性
        returntrue; // 繼續(xù)執(zhí)行鏈
    }
    
    @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, 狀態(tài)碼: {}", request.getRequestURI(), duration, response.getStatus());
    }
}

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

代碼邏輯詳解

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

深度剖析

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

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

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

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

從架構(gòu)角度，攔截器適合Web API的監(jiān)控，而AOP適合業(yè)務(wù)方法監(jiān)控。

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

方法五：過濾器（Servlet Filter）

過濾器是Servlet規(guī)范的一部分，它在請求進(jìn)入Servlet容器的最早階段被調(diào)用，可以統(tǒng)計從接收到請求到返回響應(yīng)的完整時間。

為什么用這個方法？

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

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

示例代碼

// 自定義過濾器
@Component
@Order(1) // 指定執(zhí)行順序，數(shù)字越小優(yōu)先級越高
publicclass TimeCostFilter implements Filter {
    privatestaticfinal 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); // 繼續(xù)執(zhí)行過濾器鏈
        } finally {
            long endTime = System.currentTimeMillis();
            long duration = endTime - startTime;
            HttpServletRequest httpRequest = (HttpServletRequest) request;
            HttpServletResponse httpResponse = (HttpServletResponse) response;
            logger.info("過濾器統(tǒng)計 - 接口 {} 耗時: {}ms, 狀態(tài)碼: {}", httpRequest.getRequestURI(), duration, httpResponse.getStatus());
        }
    }
}
// 注意：在Spring Boot中，@Component會自動注冊過濾器；非Spring項目需在web.xml配置

代碼邏輯詳解

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

深度剖析

過濾器的關(guān)鍵特點(diǎn)是它在整個請求處理鏈的最外層。這意味著它統(tǒng)計的時間包括：

• 過濾器鏈執(zhí)行時間。
• 攔截器執(zhí)行時間。
• Controller方法執(zhí)行時間。
• 視圖渲染時間。

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

此外，過濾器是Servlet標(biāo)準(zhǔn)，兼容任何Java Web容器（如Tomcat、Jetty），而攔截器是Spring特有。

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

但要注意，如果過濾器鏈過長，可能成為瓶頸。建議將耗時統(tǒng)計過濾器放在鏈?zhǔn)?，以獲取最準(zhǔn)確的全鏈路時間。

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

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

方法六：Micrometer和APM工具

前面五種方法適合開發(fā)和測試環(huán)境，但在生產(chǎn)環(huán)境中，我們通常需要更強(qiáng)大的工具：比如Micrometer（指標(biāo)收集庫）或APM（應(yīng)用性能管理）工具如SkyWalking。

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

為什么用這個方法？

我強(qiáng)烈推薦在生產(chǎn)環(huán)境使用專業(yè)工具。

因為它們：

• 低開銷：針對生產(chǎn)環(huán)境優(yōu)化，采集開銷可控。
• 分布式支持：在微服務(wù)架構(gòu)下，能追蹤跨服務(wù)調(diào)用鏈。
• 豐富功能：提供百分位數(shù)、均值、峰值等統(tǒng)計，并與告警系統(tǒng)集成。

示例代碼：使用Micrometer

Micrometer是一個指標(biāo)門面庫，可以對接多種監(jiān)控系統(tǒng)（如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>

然后，配置自動統(tǒng)計：

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

手動定制統(tǒng)計：

@Service
publicclass OrderService {
    privatefinal MeterRegistry meterRegistry;
    privatefinal 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(() -> {
            // 業(yè)務(wù)邏輯
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });
    }
}

代碼邏輯詳解

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

深度剖析

有些小伙伴在工作中可能覺得Micrometer配置復(fù)雜，但它的優(yōu)勢在于標(biāo)準(zhǔn)化。

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

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

它們通過字節(jié)碼增強(qiáng)（無需修改代碼）自動采集數(shù)據(jù)，并提供全鏈路追蹤。

例如，在SkyWalking中，你只需添加Java Agent，就能在UI上看到接口耗時拓?fù)鋱D。

我建議：

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

無論用哪種，核心思想是將耗時數(shù)據(jù)收集到中央系統(tǒng)，進(jìn)行聚合和告警，而不是分散在日志中。

總結(jié)

經(jīng)過以上6種方法的詳細(xì)剖析，相信你對統(tǒng)計接口耗時有了更深入的理解。

下面是我的一些實(shí)用建議：

1. 方法對比表：

2. 選擇原則：
3. • 開發(fā)/測試環(huán)境：可以用AOP或攔截器，快速驗證。
   • 生產(chǎn)環(huán)境：務(wù)必使用Micrometer或APM工具，實(shí)現(xiàn)系統(tǒng)化監(jiān)控。
   • 精度要求：高精度用nanoTime，一般用毫秒即可。
   • 代碼維護(hù)：優(yōu)先無侵入方案（AOP/攔截器），保持代碼整潔。
4. 最佳實(shí)踐：
5. • 不要過度統(tǒng)計：只關(guān)注關(guān)鍵接口，避免性能開銷。
   • 結(jié)合日志和指標(biāo)：耗時數(shù)據(jù)應(yīng)同時記錄到日志（用于調(diào)試）和指標(biāo)系統(tǒng)（用于監(jiān)控）。
   • 設(shè)置基線告警：基于歷史數(shù)據(jù)設(shè)置耗時閾值，自動觸發(fā)告警。

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

記住，統(tǒng)計接口耗時不是目的，而是手段，最終目標(biāo)是為用戶提供穩(wěn)定、快速的服務(wù)。

以上就是Java統(tǒng)計接口耗時的六種常見方法的詳細(xì)內(nèi)容，更多關(guān)于Java統(tǒng)計接口耗時的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論