IDE、终端与调试：看见程序怎样执行

IDE 能把写代码、编译、运行和调试放在一个界面，但每一步仍有各自的设置。打开 Hello.java 所在项目后，先核对 Project SDK 是 JDK 17，再检查运行配置中的主类和工作目录。IDE 内的终端通常继承启动时的环境变量。一个窗口能运行、另一个不能时，先比较 JDK 路径和启动参数，再判断是不是代码问题。

调试让你在执行途中停下来查看真实数据。断点决定在哪里暂停；变量窗口显示当前这次方法调用里的变量；调用栈显示是谁一路调用到这里。单步跳过通常执行完当前语句涉及的方法，单步进入则进入可调试的方法调用，继续运行会走到下一次暂停。先预测下一步变量应该是什么，再逐步核对，比反复猜着改更容易找到偏差。

练习时可以把整数求和的循环条件故意写错，在循环体设置断点，观察下标最后一次取值。不要在未理解原因时直接修改正在运行的变量，因为这样得到的路径可能无法复现。断点命中也不等于找到了根因：被观察的异常状态可能由更早的输入造成。记录最小输入、期望结果、实际结果和第一处偏差，再从偏差向上追溯。

运行配置决定启动哪个类、传哪些参数、使用哪个运行时，并可能指定环境变量。编辑器显示的源文件还需与实际加载的字节码对应；如果运行的是旧构建产物，光看代码会产生错觉。可以清楚地重新编译，再检查输出目录与运行目标，避免把配置差异误判成语言行为。不同 IDE 版本的菜单可能移动，但这些配置概念不会因此合并。

暂停程序后，先确认停住的是哪条线程，再选要看的那一次方法调用；调试器把每次调用显示为一个栈帧。调用者和被调用者可能都有名叫 count 的变量，选错栈帧就会看错值。观察表达式也可能改变程序：调用 getter 可能临时读取数据库等尚未加载的数据，这叫懒加载；自定义 toString 也可能执行额外逻辑。初学时先看简单字段和局部变量，避免在调试器里调用会修改数据的方法。

异常堆栈通常是 Throwable 创建时保存的调用现场，不是 catch 捕获异常那一刻的完整现场。沿着堆栈可以找出当时的方法调用关系，但它不是整个业务的时间线；异常对象后来再次被抛出，创建位置与抛出位置也可能不同。

包装异常时保留 cause，才能继续查看原来的原因。代码还可以重新填充或设置堆栈，少数异常也可能不记录堆栈。因此断点用来观察当前暂停状态，异常记录用来追查它保存下来的现场，两者应一起看。

本机 Throwable#getStackTrace 的实现先取得内部栈表示，再返回克隆数组。内部访问还包含按需构造栈元素的逻辑；教学模型直接接受已有帧，不模拟虚拟机如何捕获调用栈。理解这段代码的关键是区分数组容器与数组中的帧对象，而不是把模型当成一个真实调试器。

克隆数组会创建独立的槽位集合，所以调用者把返回数组的某项设为 null，不会通过这次赋值替换 Throwable 内部保存的项。这是防御性复制的一种用法。复制的目的并不是重新采集一次当前调用栈，也不意味着对所有可能嵌套对象都做了递归深复制。

真实实现的内部栈访问带有同步和特殊状态处理，以支持尚未初始化或不可写栈等情形。模型没有这些状态，因此只能解释普通数组隔离。阅读源码时应明确自己关注的是公开方法返回值的封装边界，不能由几行模型推断异常对象的全部线程安全性质。

调试器所显示的活动调用栈通过调试接口获取，不是简单调用每个方法的 getStackTrace。把两者类比可以帮助理解帧的排列，却不能认为异常快照会随程序继续执行而自动更新。真实系统里日志栈、追踪链路和调试现场应相互印证，单一快照无法还原全部异步调用。

事件使用 +方法 表示进入，-方法 表示退出。检查同步调用日志是否满足后进先出，返回 OK、首个错误位置或未退出状态。空日志合法；这只是单线程理想日志模型。

嵌套方法调用像一摞盘子，最后进入的方法应先退出。用双端队列的头部作栈顶，进入时压入名字，退出时检查名字是否与栈顶一致。只计数无法发现 main 与 sum 退出顺序颠倒，因此状态必须保留尚未退出的方法次序。

处理退出前先检查栈是否为空，避免多余退出事件变成队列异常。然后比较名称，发现首个不匹配就返回事件位置，不继续猜测如何修复。所有事件处理完后，栈为空才表示闭合；仍有名字说明日志缺失了退出事件，或者输入代表尚在执行的片段。

每个事件至多压栈或弹栈一次。方法名字比较还取决于名字长度，所以复杂度用总字符数描述更准确。真实线程日志可能交错，需要先按线程及执行编号分组；异常展开可能没有普通退出日志，这时应改变事件协议，不能直接指责业务调用违反了栈纪律。

每个事件读取一次，每个名字最多入栈出栈一次；substring 与相等比较的字符成本计入 L，最大栈深度不超过事件数。

生产排错先保留可复现证据：版本、请求标识、输入摘要和异常链。日志中不要记录完整凭证或大量个人数据；字段必须足以关联一次失败，又不能把排错便利等同于无限采集。常规故障优先使用有结构的日志与指标，必要时才在受控环境进行更强的现场观察。

断点会改变线程的运行和等待时间，所以一调试就不再出现的并发问题，不能据此认定已修复。条件断点、复杂表达式和大量异常断点也可能拖慢程序。改完后要用正常运行方式复测原输入；涉及并发或计时的，还要保留对应复现和负载条件。

IDE 的便利应服务于明确假设。搜索引用用来确认调用范围，跳转定义用来核实实际实现，重命名重构用来维护符号关系；它们不能替代测试。对于日志调用模型，教学算法只判断格式与嵌套，实际排错还需核对采集是否完整、线程是否混合以及日志对应哪个版本。模型成功只能证明这些输入符合约定，不能说明全部业务执行正确。