400 186 1886
前言
今天，我想和大家聊聊一個看似簡單、卻在實際項目中經常被忽略的話題：統計接口耗時。
有些小伙伴在工作中，可能經常遇到這樣的場景：線上接口突然變慢，用戶抱怨連連，你卻一頭霧水，不知道問題出在哪里。
或者，在性能優化時，你費盡心思優化了代碼，卻無法量化優化效果。
其實，這些問題都離不開一個基礎技能——如何準確統計接口耗時。
今天，我就跟大家一起聊聊統計接口耗時的6種常見方法，希望對你會有所幫助。
最近準備面試的小伙伴，可以看一下這個寶藏網站（Java突擊隊）：www.susan.net.cn，里面：面試八股文、場景設計題、面試真題、7個項目實戰、工作內推什么都有。
為什么統計接口耗時如此重要？
在深入方法之前，我們先聊聊為什么接口耗時統計這么關鍵。
從架構師的角度看，這不僅僅是“記錄一個時間”那么簡單。
接口耗時直接反映了系統性能，它是：
- 性能優化的基石：沒有耗時數據，優化就像盲人摸象，你根本不知道瓶頸在哪里。
- 監控告警的源頭：通過耗時趨勢，你可以提前發現系統異常，比如慢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
publicclass TimeCostAspect {
privatestaticfinal 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
publicclass UserService {
@TimeCost("獲取用戶信息")
public User getUserById(Long id) {
// 模擬業務邏輯
try {
Thread.sleep(50);
} catch (InterruptedException e) {
e.printStackTrace();
}
returnnew 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框架，或者需要更底層的控制，可以試試攔截器。
最近為了幫助大家找工作，專門建了一些工作內推群，各大城市都有，歡迎各位HR和找工作的小伙伴進群交流，群里目前已經收集了不少的工作內推崗位。加蘇三的微信：li_su223，備注：掘金+所在城市，即可進群。
方法四：使用攔截器（Interceptor）
在Web應用中，攔截器是另一種常見的AOP實現方式，專門用于處理HTTP請求。
Spring MVC提供了HandlerInterceptor，可以攔截Controller方法的執行。
為什么用這個方法？
攔截器針對Web請求優化，它可以獲取HTTP上下文信息（如請求參數、響應狀態），非常適合統計接口級耗時。
相比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; // 繼續執行鏈
}
@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
publicclass 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) // 指定執行順序，數字越小優先級越高
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); // 繼續執行過濾器鏈
} 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
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(() -> {
// 業務邏輯
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/攔截器），保持代碼整潔。
- 最佳實踐：
- 不要過度統計：只關注關鍵接口，避免性能開銷。
- 結合日志和指標：耗時數據應同時記錄到日志（用于調試）和指標系統（用于監控）。
- 設置基線告警：基于歷史數據設置耗時閾值，自動觸發告警。
有些小伙伴在工作中，可能一開始覺得這些方法很復雜，但一旦掌握，就能在性能優化和故障排查中游刃有余。
記住，統計接口耗時不是目的，而是手段，最終目標是為用戶提供穩定、快速的服務。
