这可能是一个奇怪的问题，但是在服务器环境中，“try-catch”块是否会比仅运行特定的代码块更多地添加到内存中。例如，如果我执行打印堆栈跟踪，JVM 是否会保留更多信息。还是堆上保留了更多信息？
try {
... do something()
} catch(Exception e) {
e.printStackTrace();
}
... do something()
【问题讨论】：
标签： java memory exception-handling
异常将引用堆栈跟踪。 printStackTrace 将分配更多内存，因为它将堆栈跟踪格式化为漂亮的东西。
try catch 块可能会导致大部分静态代码/数据段，但不会导致运行时内存分配
【讨论】：
这里重要的是，一旦异常变量“e”不再可访问（即超出范围），它就有资格进行内存收集。
【讨论】：
堆栈跟踪是在创建异常时构建的。打印堆栈跟踪不会比打印其他任何内容更占用内存。
try/catch 块可能有一些性能开销，但不会以增加内存需求的形式出现。
【讨论】：
在大多数情况下，发生异常时不必担心内存/性能。如果您有一个通用代码路径的异常，则表明您在滥用异常。
如果您的问题更多是出于学术目的，那么我不知道堆/内存空间方面的全部情况。然而，Joshua Bloch 在“Effective Java”中提到，try catch 块的 catch 块通常相对来说没有被大多数 JVM 实现优化。
【讨论】：
从技术上讲，您的问题的答案可能是否定的。有很多理由尽可能避免抛出异常，但内存并不是真正的问题。
只在真正异常的情况下抛出异常的真正原因是它很慢。生成异常涉及仔细检查堆栈。这根本不是一个快速的操作。如果您将其作为定期执行流程的一部分，它将明显影响您的速度。我曾经写过一个我认为非常聪明的日志系统，因为它通过生成异常并以这种方式检查堆栈来自动找出哪个类调用了它。最终我不得不回去把那部分拿出来，因为它明显减慢了其他一切。
【讨论】：
虽然与内存消耗没有直接关系，但前段时间这里有一个帖子讨论How slow are the Java exceptions?，我认为值得一看。
我的书签中也有这个link。据我记得，它提供了一个示例，说明在抛出异常时跳过堆栈跟踪生成可能会加快速度，但该站点现在似乎已关闭。
【讨论】：