400 186 1886
前言
今天，我想和大家聊聊一個(gè)看似簡(jiǎn)單、卻在實(shí)際項(xiàng)目中經(jīng)常被忽略的話題：統(tǒng)計(jì)接口耗時(shí)。
有些小伙伴在工作中，可能經(jīng)常遇到這樣的場(chǎng)景：線上接口突然變慢，用戶抱怨連連，你卻一頭霧水，不知道問題出在哪里。
或者，在性能優(yōu)化時(shí)，你費(fèi)盡心思優(yōu)化了代碼，卻無法量化優(yōu)化效果。
其實(shí)，這些問題都離不開一個(gè)基礎(chǔ)技能——如何準(zhǔn)確統(tǒng)計(jì)接口耗時(shí)。
今天，我就跟大家一起聊聊統(tǒng)計(jì)接口耗時(shí)的6種常見方法，希望對(duì)你會(huì)有所幫助。
為什么統(tǒng)計(jì)接口耗時(shí)如此重要？
在深入方法之前，我們先聊聊為什么接口耗時(shí)統(tǒng)計(jì)這么關(guān)鍵。
從架構(gòu)師的角度看，這不僅僅是“記錄一個(gè)時(shí)間”那么簡(jiǎn)單。
接口耗時(shí)直接反映了系統(tǒng)性能，它是：
- 性能優(yōu)化的基石：沒有耗時(shí)數(shù)據(jù)，優(yōu)化就像盲人摸象，你根本不知道瓶頸在哪里。
- 監(jiān)控告警的源頭：通過耗時(shí)趨勢(shì)，你可以提前發(fā)現(xiàn)系統(tǒng)異常，比如慢SQL、資源競(jìng)爭(zhēng)等問題。
- 用戶體驗(yàn)的晴雨表：接口響應(yīng)時(shí)間直接影響用戶滿意度，尤其在高并發(fā)場(chǎng)景下，幾毫秒的延遲都可能造成流失。
舉個(gè)例子，有些小伙伴在工作中，可能直接用System.currentTimeMillis()在方法開始和結(jié)束處打日志，覺得這很簡(jiǎn)單。但如果你在多線程環(huán)境下這么做，可能會(huì)發(fā)現(xiàn)數(shù)據(jù)不準(zhǔn)，因?yàn)橄到y(tǒng)時(shí)間可能被調(diào)整，或者日志輸出本身影響性能。
這就是為什么我們需要更專業(yè)的方法。
好了，廢話不多說，讓我們開始今天的主菜。我將從最簡(jiǎn)單的原生Java方法，逐步深入到分布式系統(tǒng)中的高級(jí)工具，確保每種方法都講透、講懂。
方法一：System.currentTimeMillis()
這是最基礎(chǔ)、最直接的方法，估計(jì)每個(gè)Java程序員都用過。
它的原理很簡(jiǎn)單：在方法開始時(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(); // 記錄開始時(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)中。
深度剖析
有些小伙伴在工作中可能覺得這方法太“土”，但它其實(shí)有幾個(gè)隱藏問題：
- 精度問題：
System.currentTimeMillis()的精度是毫秒，對(duì)于短時(shí)間操作（比如幾毫秒內(nèi)的調(diào)用），可能無法準(zhǔn)確測(cè)量。如果你需要更高精度，可以用System.nanoTime()，它返回納秒級(jí)時(shí)間，但注意它不表示實(shí)際時(shí)間，只適合計(jì)算相對(duì)時(shí)間差。 - 系統(tǒng)時(shí)間影響：如果系統(tǒng)時(shí)間在過程中被調(diào)整（比如NTP同步），
currentTimeMillis可能回退或跳躍，導(dǎo)致計(jì)算出的耗時(shí)為負(fù)數(shù)或異常值。nanoTime不受此影響，因?yàn)樗谙到y(tǒng)啟動(dòng)時(shí)間。 - 代碼侵入性：你需要手動(dòng)在每個(gè)方法中添加代碼，如果接口眾多，會(huì)顯得臃腫，且容易遺漏。
為了更直觀地理解這個(gè)過程，我畫了一個(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í)。
接下來，我們會(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í)開始時(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í)間差有意義。- 我們同樣在開始和結(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è)差異可以忽略。 - 溢出問題：
nanoTime的值可能溢出（雖然很少見），但因?yàn)槭怯?jì)算差值，只要時(shí)間間隔不超過292年（2^63納秒），就不會(huì)有問題。
我建議：如果需要高精度測(cè)量，就用nanoTime；如果只是大概記錄，用currentTimeMillis即可。
但這兩種方法都有代碼侵入性問題，接下來我們看看如何用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í)的方法。這樣，我們可以在任何方法上添加它，而無需修改方法內(nèi)部代碼。 - 切面類：
TimeCostAspect使用@Aspect和@Component注解，表示這是一個(gè)Spring管理的切面。 @Around注解定義了環(huán)繞通知，它會(huì)在目標(biāo)方法執(zhí)行前后被調(diào)用。ProceedingJoinPoint參數(shù)代表被攔截的方法，proceed()方法用于執(zhí)行原始方法。- 我們?cè)?code style="font-family: Menlo, Monaco, Consolas, "Courier New", monospace; font-size: 0.87em; word-break: break-word; border-radius: 2px; overflow-x: auto; background-color: rgb(255, 245, 245); color: rgb(255, 80, 44); padding: 0.065em 0.4em;">proceed()前后記錄時(shí)間，并計(jì)算耗時(shí)。
- 使用日志記錄耗時(shí)，避免控制臺(tái)輸出影響性能。
- 業(yè)務(wù)方法：在
getUserById方法上添加@TimeCost，即可自動(dòng)統(tǒng)計(jì)耗時(shí)。
深度剖析
有些小伙伴在工作中可能對(duì)AOP的底層原理感興趣。簡(jiǎn)單來說，Spring AOP基于動(dòng)態(tài)代理實(shí)現(xiàn)：
- 如果目標(biāo)類實(shí)現(xiàn)了接口，Spring使用JDK動(dòng)態(tài)代理。
- 如果沒實(shí)現(xiàn)接口，使用CGLIB字節(jié)碼增強(qiáng)。
這帶來了一個(gè)關(guān)鍵點(diǎn)：AOP只能攔截Spring管理的Bean方法，對(duì)于私有方法或非Bean對(duì)象無效。
此外，環(huán)繞通知的順序也可能影響行為，如果有多個(gè)切面，可以用@Order注解控制順序。
從性能角度看，AOP引入了一定的開銷（代理調(diào)用），但在大多數(shù)應(yīng)用中可忽略。它的最大優(yōu)勢(shì)是解耦，讓業(yè)務(wù)代碼保持純凈。
為了展示AOP的工作流程，我畫了一個(gè)序列圖：
適用場(chǎng)景
- Spring項(xiàng)目，需要無侵入統(tǒng)計(jì)。
- 多個(gè)方法需要統(tǒng)一處理耗時(shí)邏輯。
- 團(tuán)隊(duì)協(xié)作時(shí)，避免業(yè)務(wù)代碼被“污染”。
AOP雖然強(qiáng)大，但依賴于Spring框架。
如果你在用其他Web框架，或者需要更底層的控制，可以試試攔截器。
最近為了幫助大家找工作，專門建了一些工作內(nèi)推群，各大城市都有，歡迎各位HR和找工作的小伙伴進(jìn)群交流，群里目前已經(jīng)收集了不少的工作內(nèi)推崗位。加蘇三的微信：li_su223，備注：掘金+所在城市，即可進(jìn)群。
方法四：使用攔截器（Interceptor）
在Web應(yīng)用中，攔截器是另一種常見的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); // 將開始時(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è)谶@里記錄開始時(shí)間，并存入請(qǐng)求屬性（HttpServletRequest），以便后續(xù)使用。afterCompletion在請(qǐng)求完成后調(diào)用（包括視圖渲染后），我們?cè)谶@里取出開始時(shí)間，計(jì)算總耗時(shí)。- 注意：
afterCompletion即使請(qǐng)求拋出異常也會(huì)調(diào)用，這確保了耗時(shí)統(tǒng)計(jì)的完整性。
- 注冊(cè)攔截器：通過
WebMvcConfigurer的addInterceptors方法，將攔截器注冊(cè)到Spring MVC中，并指定攔截路徑（這里是所有路徑）。
深度剖析
有些小伙伴在工作中可能問：攔截器和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è)常見陷阱是：攔截器統(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é)合使用，覆蓋不同層次。
方法五：過濾器（Servlet Filter）
過濾器是Servlet規(guī)范的一部分，它在請(qǐng)求進(jìn)入Servlet容器的最早階段被調(diào)用，可以統(tǒng)計(jì)從接收到請(qǐng)求到返回響應(yīng)的完整時(shí)間。
為什么用這個(gè)方法？
過濾器比攔截器更“底層”，它可以攔截所有請(qǐng)求（包括靜態(tài)資源），且不依賴Spring框架。
如果你在用純Servlet應(yīng)用，或者需要統(tǒng)計(jì)整個(gè)請(qǐng)求生命周期，過濾器是理想選擇。
示例代碼
// 自定義過濾器
@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í)行過濾器鏈
} finally {
long endTime = System.currentTimeMillis();
long duration = endTime - startTime;
HttpServletRequest httpRequest = (HttpServletRequest) request;
HttpServletResponse httpResponse = (HttpServletResponse) response;
logger.info("過濾器統(tǒng)計(jì) - 接口 {} 耗時(shí): {}ms, 狀態(tài)碼: {}", httpRequest.getRequestURI(), duration, httpResponse.getStatus());
}
}
}
// 注意：在Spring Boot中，@Component會(huì)自動(dòng)注冊(cè)過濾器；非Spring項(xiàng)目需在web.xml配置
代碼邏輯詳解
- 實(shí)現(xiàn)
Filter接口，重寫doFilter方法。 - 在
doFilter開始時(shí)記錄時(shí)間，然后調(diào)用chain.doFilter()將請(qǐng)求傳遞給下一個(gè)過濾器或Servlet。 - 在
finally塊中計(jì)算耗時(shí)，確保即使拋出異常也能記錄。 - 將
ServletRequest和ServletResponse轉(zhuǎn)換為HTTP類型，以獲取URI和狀態(tài)碼。 @Order(1)指定過濾器執(zhí)行順序，如果有多個(gè)過濾器，順序很重要。
深度剖析
過濾器的關(guān)鍵特點(diǎn)是它在整個(gè)請(qǐng)求處理鏈的最外層。這意味著它統(tǒng)計(jì)的時(shí)間包括：
- 過濾器鏈執(zhí)行時(shí)間。
- 攔截器執(zhí)行時(shí)間。
- Controller方法執(zhí)行時(shí)間。
- 視圖渲染時(shí)間。
有些小伙伴在工作中可能發(fā)現(xiàn)過濾器耗時(shí)比攔截器長(zhǎng)，原因就在于此。
此外，過濾器是Servlet標(biāo)準(zhǔn)，兼容任何Java Web容器（如Tomcat、Jetty），而攔截器是Spring特有。
從性能視角，過濾器非常高效，因?yàn)樗苯忧度隨ervlet容器。
但要注意，如果過濾器鏈過長(zhǎng)，可能成為瓶頸。建議將耗時(shí)統(tǒng)計(jì)過濾器放在鏈?zhǔn)?，以獲取最準(zhǔn)確的全鏈路時(shí)間。
為了對(duì)比過濾器、攔截器和AOP的范圍，我畫了一個(gè)層次圖：
這個(gè)圖清晰展示了三者的執(zhí)行順序和范圍：過濾器最外層，攔截器在Spring MVC層，AOP在業(yè)務(wù)方法層。
方法六：Micrometer和APM工具
前面五種方法適合開發(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)樗鼈儯?/p>
- 低開銷：針對(duì)生產(chǎn)環(huán)境優(yōu)化，采集開銷可控。
- 分布式支持：在微服務(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ì)：
// 無需額外代碼，Spring Boot自動(dòng)集成Micrometer，通過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ù)可以通過
/actuator/prometheus端點(diǎn)暴露，供Prometheus采集。
深度剖析
有些小伙伴在工作中可能覺得Micrometer配置復(fù)雜，但它的優(yōu)勢(shì)在于標(biāo)準(zhǔn)化。
你只需寫一次代碼，就能對(duì)接多種監(jiān)控后端。
對(duì)于更復(fù)雜的場(chǎng)景，APM工具如SkyWalking是更好的選擇。
它們通過字節(jié)碼增強(qiáng)（無需修改代碼）自動(dòng)采集數(shù)據(jù)，并提供全鏈路追蹤。
例如，在SkyWalking中，你只需添加Java Agent，就能在UI上看到接口耗時(shí)拓?fù)鋱D。
我建議：
- 中小項(xiàng)目：用Micrometer + Prometheus + Grafana，成本低，功能強(qiáng)大。
- 大型分布式系統(tǒng)：用APM工具如SkyWalking或Pinpoint，它們提供更細(xì)致的鏈路分析。
無論用哪種，核心思想是將耗時(shí)數(shù)據(jù)收集到中央系統(tǒng)，進(jìn)行聚合和告警，而不是分散在日志中。
總結(jié)
經(jīng)過以上6種方法的詳細(xì)剖析，相信你對(duì)統(tǒng)計(jì)接口耗時(shí)有了更深入的理解。
下面是我的一些實(shí)用建議：
- 方法對(duì)比表：
| 方法 | 優(yōu)點(diǎn) | 缺點(diǎn) | 適用場(chǎng)景 |
|---|---|---|---|
| System.currentTimeMillis() | 簡(jiǎn)單、無需依賴 | 精度低、代碼侵入 | 本地測(cè)試、簡(jiǎn)單調(diào)試 |
| System.nanoTime() | 精度高 | 代碼侵入、需轉(zhuǎn)換單位 | 高性能測(cè)量、算法優(yōu)化 |
| Spring AOP | 無侵入、解耦 | 僅Spring Bean、有代理開銷 | 業(yè)務(wù)方法監(jiān)控、Spring項(xiàng)目 |
| 攔截器 | Web優(yōu)化、獲取HTTP上下文 | 僅Web請(qǐng)求、包括視圖時(shí)間 | Web API監(jiān)控 |
| 過濾器 | 底層、全鏈路 | 包括所有過濾器時(shí)間 | 全請(qǐng)求生命周期統(tǒng)計(jì) |
| Micrometer/APM | 生產(chǎn)級(jí)、分布式支持 | 配置復(fù)雜、需基礎(chǔ)設(shè)施 | 生產(chǎn)環(huán)境、微服務(wù)架構(gòu) |
- 選擇原則：
- 開發(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)先無侵入方案（AOP/攔截器），保持代碼整潔。
- 最佳實(shí)踐：
- 不要過度統(tǒng)計(jì)：只關(guān)注關(guān)鍵接口，避免性能開銷。
- 結(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ā)告警。
有些小伙伴在工作中，可能一開始覺得這些方法很復(fù)雜，但一旦掌握，就能在性能優(yōu)化和故障排查中游刃有余。
記住，統(tǒng)計(jì)接口耗時(shí)不是目的，而是手段，最終目標(biāo)是為用戶提供穩(wěn)定、快速的服務(wù)。
