【问题标题】:Does the placement of a try-catch block affect performance?try-catch 块的放置会影响性能吗?
【发布时间】:2010-07-27 03:28:48
【问题描述】:

try-catch 块的放置会影响性能吗?

示例 1:try-catch 块 while 循环

while (true) {
    try {
        // ... read from a file
    } catch (EOFException e) {
        break;
    }
}

示例 2:try-catch 块环绕 while-loop

try {
    while (true) {
        // ... read from a file
    } 
} catch (EOFException e) {
    // :P
}

从逻辑上讲,这两个例子是等价的,但我应该更喜欢哪个?

【问题讨论】:

  • 两个代码示例不等价。
  • 是的,在第二种情况下,您当然不希望 break; 要么您的程序无法编译,要么您将跳出错误的循环。
  • 正如其他人所指出的,代码示例并不相同。如果你不在一个循环中,你就不能真正从中刹车。无论如何,是什么阻止您对其进行基准测试?这是相当简单的基准代码。
  • @krock: 我在等别人说这个;在高层次上,它在我的代码中是等价的。稍后我会发布一个完整的代码示例,但希望你能理解这个问题。
  • @all: 第二次中断是复制/粘贴的错误。

标签: java performance try-catch


【解决方案1】:

Should java try blocks be scoped as tightly as possible?

这给出了比我更好的答案。简而言之,他们只在抛出异常时检查的表中添加一个条目,因此除非抛出异常,否则它们不会影响性能。如果可以的话,最好把它放在最适合尝试恢复的地方。如果没有,任何地方都是有用的或有意义的。 虽然在循环外有 break ,但我认为第二个无论如何都不是有效的。

【讨论】:

  • 第二次中断是复制/粘贴的错误。
【解决方案2】:

try-catch 产生的任何开销都可能可以忽略不计,但第一种情况更引起我注意的是它具有误导性:您正在捕获异常,只是为了中止循环。我会选择解决方案 2,因为它与意图一致。这样可以避免任何开销。

【讨论】:

  • 第二次中断是复制/粘贴的错误。
  • 我什么也没说。我知道这是一个错误并忽略了它,因为您已经明确表达了您的意图。
【解决方案3】:

try-catch 的放置对应用程序的性能没有任何影响。即使它确实如此,它也完全可以忽略不计,这不是你想要引导你的能量的地方。先根据需要实施,再优化。不要微优化。

【讨论】:

    【解决方案4】:

    你能从外面休息一下吗?我不认为你的假设是 2 是等价的。

    我的直觉告诉我,循环外的 try/catch 更好。如果通过编写 try/catch 对字节码产生影响,那么创建的越少越好。如果除非发生异常,否则没有影响,那么没关系。我没有看到任何情况下在里面有 try/catch 会更好。

    我可能是错的......

    【讨论】:

    • 第二次中断是复制/粘贴的错误。
    【解决方案5】:

    第二个例子(try-catch 块包围代码)更快更清晰。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2011-04-09
      • 2022-01-13
      • 1970-01-01
      • 2013-05-22
      • 1970-01-01
      • 2019-08-02
      • 1970-01-01
      相关资源
      最近更新 更多