Building a Java Method Call‑Stack Tracing Tool to Accelerate Issue Diagnosis
This article describes the pain points of daily on‑call debugging, explains how Java StackTraceElement can be leveraged to construct a chain‑style call‑stack visualizer, details the implementation of a lightweight tracing utility with configurable filters, and demonstrates its integration and practical usage in production environments.
The article starts by outlining common on‑call troubleshooting scenarios where developers receive error screenshots and need to extract as much context as possible, such as menu names, error messages, and auxiliary data like SKU or location codes.
It then discusses typical investigation steps, including verifying the serial number, checking its status, searching the codebase for the error message, and handling cases where the same message appears in multiple locations.
Inspired by Java's exception stack traces, the author notes that each StackTraceElement contains the fully qualified class name, method name, file name, and line number, which together form a precise execution trace.
Using this insight, a custom tool was built that filters and formats the stack frames, optionally removing middleware, proxy, and framework‑generated entries, and presents the call chain in a readable, linear format.
The core implementation relies on the JDK's StackTraceElement class; the tool extracts the necessary fields, applies filters such as pretty (class and method only), simple (removes proxy methods), and specifiedPrefix (keeps only designated package prefixes), and assembles the result.
Typical filter targets include FastClassBySpringCGLIB , EnhancerBySpringCGLIB , lambda$ , Aspect , and Interceptor . Default helper methods are also provided for convenient usage.
Usage examples show how to invoke the utility via static methods such as StackTraceUtils#simpleTrace() , StackTraceUtils#trace() , and their overloaded variants that accept custom prefixes or boolean flags.
Integration steps are illustrated with Maven dependency snippets:
<dependency>
<groupId>com.jd.sword</groupId>
<artifactId>sword-utils-common</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>Configuration in mybatis XML enables the stack‑trace feature and limits tracing to specific packages, with sampling rates to control overhead:
<plugin interceptor="com.jd.sword.mybatis.plugin.sql.SQLMarkingInterceptor">
<property name="enabled" value="true"/>
<property name="stackTraceEnabled" value="true"/>
<property name="specifiedStackTracePackages" value="com.jdwl.wms.stock"/>
<property name="stackTraceSamplingRate" value="1/2"/>
</plugin>In production, the tool helps locate the entry point of a request by tracing from the controller method through service and repository layers, as shown in the example call chain for an offShelf operation.
Applicable scenarios include logging stack traces for business exceptions, enriching monitoring alerts with call‑stack data, and visualizing complex method reuse paths.
The article also mentions extending an existing SQL‑coloring plugin with the new stack‑trace information, providing upgrade instructions and Maven coordinates for the latest version.
Overall, the utility offers a practical way to transform raw stack traces into concise, filtered call‑stack representations, improving debugging efficiency for backend Java services.
JD Tech Talk
Official JD Tech public account delivering best practices and technology innovation.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.