怎么用 Thread.currentThread().getStackTrace() 拿到当前方法名
Java 没有像 Python 的 inspect.currentframe().f_code.co_name 那样直白的 API，最常用、最轻量的方式就是靠 getStackTrace() 手动解析堆栈数组。它返回 StackTraceElement[]，索引越小越靠近当前调用点。
关键在于：你调用它的那一行，本身会出现在堆栈第 2 或第 3 层（取决于是否在静态工具方法里封装），不是第 0 层——第 0 层是 getStackTrace() 自身的 native 方法，第 1 层是它所在的栈帧（比如你封装的工具方法），真正“你的方法”通常在索引 2。
- 直接在业务方法里写：
Thread.currentThread().getStackTrace()[2].getMethodName() - 如果封装成公共工具方法（比如
getCurrentMethodName()），那要用[3]，因为调用栈多了一层 - 别依赖
[0]或[1]，不同 JVM 实现或 JIT 优化下可能不稳定 - 注意：这个操作有开销，频繁调用（如循环内）会明显拖慢性能
为什么 new Throwable().getStackTrace() 更可靠但更重
Throwable 构造时强制捕获完整堆栈快照，比 Thread.getStackTrace() 更稳定，尤其在某些 JDK 版本或开启栈压缩时，前者可能返回截断结果，后者不会。
但它代价更高：每次都要实例化一个异常对象，触发完整的异常创建逻辑（填充栈、填充 cause、初始化 message 等），GC 压力和 CPU 开销都明显上升。
立即学习“Java免费学习笔记（深入）”；
- 适合调试、日志打点、低频诊断场景，比如 AOP 切面记录入口方法名
- 不适合高频路径，比如每毫秒调用一次的监控钩子
- 获取方法名写法：(
new Throwable().getStackTrace()[2].getMethodName())，同样要跳过前两层 - 注意：JVM 参数
-XX:-OmitStackTraceInFastThrow可能影响首次异常的栈完整性，但对后续新建的Throwable无影响
用 SecurityManager 获取调用方方法名？别试了
老代码里偶见通过自定义 SecurityManager 的 getClassContext() 来取类/方法，但这在 JDK 9+ 已被标记为 deprecated，JDK 17 默认移除，JDK 21 完全不可用。连启动参数 --illegal-access=permit 都救不了它。
- 现代 JDK 下运行直接抛
UnsupportedOperationException - 即使降级到 JDK 8，
SecurityManager本身已被弃用多年，且默认禁用，启用需额外 JVM 参数并承担安全模型负担 - 没有迁移价值，纯属历史包袱，看到就删
实际日志场景中该选哪个：方法名 + 行号要不要一起拿
生产环境打日志时，光有方法名往往不够，结合行号才能快速定位；但行号在代码重构后容易失效，而方法名相对稳定。两者权衡看用途。
- 调试期快速定位：用
getMethodName() + getLineNumber()，例如log.info("{}:{} - {}", ste.getMethodName(), ste.getLineNumber(), msg) - 监控告警或聚合分析：只取
getMethodName()，避免因行号变动导致指标分裂 - 注意：
getLineNumber()在编译开启-g:none（无调试信息）时返回 -1，确保构建时保留 line number（Maven 默认保留） - 如果用了 Lombok 的
@Log或 SLF4J 的LoggerFactory.getLogger(Class)，它们不自动注入方法名，得自己拼
最易被忽略的一点：所有这些方式拿到的都是「调用栈上层的方法」，不是当前正在执行的字节码指令所属方法——如果你在 lambda、匿名内部类或反射调用里用，得到的是外层宿主方法名，不是 lambda 本身的“名字”（它根本没有）。想区分这类情况，得结合 ste.getClassName() 和字节码分析，那就超出简单追踪范围了。
