統(tǒng)計(jì)接口耗時(shí)的六種常見(jiàn)方法

作者：蘇三 2025-10-21 02:00:00

今天，我想和大家聊聊一個(gè)看似簡(jiǎn)單、卻在實(shí)際項(xiàng)目中經(jīng)常被忽略的話題：統(tǒng)計(jì)接口耗時(shí)。有些小伙伴在工作中，可能經(jīng)常遇到這樣的場(chǎng)景：線上接口突然變慢，用戶抱怨連連，你卻一頭霧水，不知道問(wèn)題出在哪里。或者，在性能優(yōu)化時(shí)，你費(fèi)盡心思優(yōu)化了代碼，卻無(wú)法量化優(yōu)化效果。

前言

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

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

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

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

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

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

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

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

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

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

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

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

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

方法一：System.currentTimeMillis()

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

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

為什么用這個(gè)方法？

對(duì)于一些簡(jiǎn)單的場(chǎng)景，比如測(cè)試某個(gè)方法塊的執(zhí)行時(shí)間，這種方法快速有效。

它不依賴任何第三方庫(kù)，純?cè)鶭ava實(shí)現(xiàn)。

示例代碼

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

代碼邏輯詳解

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

深度剖析

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

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

為了更直觀地理解這個(gè)過(guò)程，我畫了一個(gè)流程圖，展示了手動(dòng)計(jì)時(shí)的基本流程：

圖片

適用場(chǎng)景

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

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

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

方法二：System.nanoTime()

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

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

為什么用這個(gè)方法？

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

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

示例代碼

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

代碼邏輯詳解

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

深度剖析

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

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

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

但這兩種方法都有代碼侵入性問(wèn)題，接下來(lái)我們看看如何用AOP解決。

方法三：Spring AOP

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

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

為什么用這個(gè)方法？

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

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

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

示例代碼

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

// 定義一個(gè)注解，用于標(biāo)記需要統(tǒng)計(jì)耗時(shí)的方法
@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("方法 {} 耗時(shí): {}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是一個(gè)自定義注解，用于標(biāo)記需要統(tǒng)計(jì)耗時(shí)的方法。這樣，我們可以在任何方法上添加它，而無(wú)需修改方法內(nèi)部代碼。
切面類：TimeCostAspect使用@Aspect和@Component注解，表示這是一個(gè)Spring管理的切面。

@Around注解定義了環(huán)繞通知，它會(huì)在目標(biāo)方法執(zhí)行前后被調(diào)用。

ProceedingJoinPoint參數(shù)代表被攔截的方法，proceed()方法用于執(zhí)行原始方法。

我們?cè)?/span>proceed()前后記錄時(shí)間，并計(jì)算耗時(shí)。

使用日志記錄耗時(shí)，避免控制臺(tái)輸出影響性能。

業(yè)務(wù)方法：在getUserById方法上添加@TimeCost，即可自動(dòng)統(tǒng)計(jì)耗時(shí)。

深度剖析

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

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

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

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

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

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

圖片

適用場(chǎng)景

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

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

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

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

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

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

為什么用這個(gè)方法？

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

相比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); // 將開(kāi)始時(shí)間存入請(qǐng)求屬性
        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("接口 {} 耗時(shí): {}ms, 狀態(tài)碼: {}", request.getRequestURI(), duration, response.getStatus());
    }
}

// 注冊(cè)攔截器到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)用，我們?cè)谶@里記錄開(kāi)始時(shí)間，并存入請(qǐng)求屬性（HttpServletRequest），以便后續(xù)使用。

afterCompletion在請(qǐng)求完成后調(diào)用（包括視圖渲染后），我們?cè)谶@里取出開(kāi)始時(shí)間，計(jì)算總耗時(shí)。

注意：afterCompletion即使請(qǐng)求拋出異常也會(huì)調(diào)用，這確保了耗時(shí)統(tǒng)計(jì)的完整性。

注冊(cè)攔截器：通過(guò)WebMvcConfigurer的addInterceptors方法，將攔截器注冊(cè)到Spring MVC中，并指定攔截路徑（這里是所有路徑）。

深度剖析

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

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

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

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

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

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

方法五：過(guò)濾器（Servlet Filter）

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

為什么用這個(gè)方法？

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

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

示例代碼

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

代碼邏輯詳解

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

深度剖析

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

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

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

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

從性能視角，過(guò)濾器非常高效，因?yàn)樗苯忧度隨ervlet容器。

但要注意，如果過(guò)濾器鏈過(guò)長(zhǎng)，可能成為瓶頸。建議將耗時(shí)統(tǒng)計(jì)過(guò)濾器放在鏈?zhǔn)祝垣@取最準(zhǔn)確的全鏈路時(shí)間。

為了對(duì)比過(guò)濾器、攔截器和AOP的范圍，我畫了一個(gè)層次圖：

圖片

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

方法六：Micrometer和APM工具

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

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

為什么用這個(gè)方法？

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

因?yàn)樗鼈儯?/span>

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

示例代碼：使用Micrometer

Micrometer是一個(gè)指標(biāo)門面庫(kù)，可以對(duì)接多種監(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>

然后，配置自動(dòng)統(tǒng)計(jì)：

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

手動(dòng)定制統(tǒng)計(jì)：

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

代碼邏輯詳解

自動(dòng)統(tǒng)計(jì)：Spring Boot Actuator自動(dòng)為Web請(qǐng)求生成指標(biāo)（如http.server.requests），包括耗時(shí)、狀態(tài)碼等。
手動(dòng)定制：我們注入MeterRegistry，創(chuàng)建一個(gè)Timer指標(biāo)，用于測(cè)量特定方法耗時(shí)。

Timer.record()方法接受一個(gè)Runnable或Callable，自動(dòng)記錄執(zhí)行時(shí)間。

指標(biāo)數(shù)據(jù)可以通過(guò)/actuator/prometheus端點(diǎn)暴露，供Prometheus采集。

深度剖析

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

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

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

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

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

我建議：

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

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

總結(jié)

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

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

方法對(duì)比表：

方法	優(yōu)點(diǎn)	缺點(diǎn)	適用場(chǎng)景
System.currentTimeMillis()	簡(jiǎn)單、無(wú)需依賴	精度低、代碼侵入	本地測(cè)試、簡(jiǎn)單調(diào)試
System.nanoTime()	精度高	代碼侵入、需轉(zhuǎn)換單位	高性能測(cè)量、算法優(yōu)化
Spring AOP	無(wú)侵入、解耦	僅Spring Bean、有代理開(kāi)銷	業(yè)務(wù)方法監(jiān)控、Spring項(xiàng)目
攔截器	Web優(yōu)化、獲取HTTP上下文	僅Web請(qǐng)求、包括視圖時(shí)間	Web API監(jiān)控
過(guò)濾器	底層、全鏈路	包括所有過(guò)濾器時(shí)間	全請(qǐng)求生命周期統(tǒng)計(jì)
Micrometer/APM	生產(chǎn)級(jí)、分布式支持	配置復(fù)雜、需基礎(chǔ)設(shè)施	生產(chǎn)環(huán)境、微服務(wù)架構(gòu)

選擇原則：

開(kāi)發(fā)/測(cè)試環(huán)境：可以用AOP或攔截器，快速驗(yàn)證。
生產(chǎn)環(huán)境：務(wù)必使用Micrometer或APM工具，實(shí)現(xiàn)系統(tǒng)化監(jiān)控。
精度要求：高精度用nanoTime，一般用毫秒即可。
代碼維護(hù)：優(yōu)先無(wú)侵入方案（AOP/攔截器），保持代碼整潔。

最佳實(shí)踐：

不要過(guò)度統(tǒng)計(jì)：只關(guān)注關(guān)鍵接口，避免性能開(kāi)銷。
結(jié)合日志和指標(biāo)：耗時(shí)數(shù)據(jù)應(yīng)同時(shí)記錄到日志（用于調(diào)試）和指標(biāo)系統(tǒng)（用于監(jiān)控）。
設(shè)置基線告警：基于歷史數(shù)據(jù)設(shè)置耗時(shí)閾值，自動(dòng)觸發(fā)告警。

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

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

責(zé)任編輯：武曉燕來(lái)源：蘇三說(shuō)技術(shù)