try-catch是否会降低效率？两种Java除法判断方法是否存在效率差异？

嗨，咱们来逐个拆解这两个Java相关的问题：

其实得分两种场景来看：

• 正常执行路径（没有异常抛出）：现代JVM（比如HotSpot）对try-catch块的优化已经非常成熟了，这种情况下几乎不会带来额外的性能开销。JVM会把try块里的代码当成普通代码来执行，不会因为包裹了try-catch就变慢。
• 异常抛出路径：这时候开销就非常大了！因为抛出异常时，JVM需要创建异常对象，还要收集当前线程的栈跟踪信息——这一步得遍历整个调用栈，生成每个栈帧的详细信息，是很耗时的操作。而且异常处理的流程也会打断正常的代码执行流程，带来额外的性能损耗。

说白了，try-catch本身不是性能杀手，异常的抛出和捕获才是。

答案是：有明显的效率差异，方法二比方法一高效得多，核心原因在于异常处理的开销，具体分析如下：
先把两个方法的代码再明确下：
方法一代码：

public boolean canDivisionBeDone(int iA, int iB){ 
    try{ 
        float a = iA/iB; 
    }catch(Exception e){ 
        return false; 
    } 
    return true; 
}

方法二代码：

public boolean canDivisionBeDone(int iA, int iB){ 
    if(iB == 0){ 
        return false; 
    }else{ 
        float a = iA/iB; 
    } 
    return true; 
}

差异的关键点：

• 异常场景（iB=0）：方法一触发ArithmeticException，JVM要执行创建异常对象、收集栈轨迹等一系列高开销操作；而方法二只是做一个简单的整数相等判断iB == 0，这是CPU能瞬间完成的轻量操作，两者的性能差距会非常大。
• 正常场景（iB≠0）：虽然现代JVM对try-catch的正常路径优化不错，但方法二的逻辑是提前预判了错误可能性，直接跳过了异常处理的潜在逻辑，代码更简洁直接，JVM的优化空间也更大，执行效率至少不会比方法一差，甚至略优。

另外从代码规范角度说一句：用try-catch来处理这种**可以提前预判的错误（除数为0是明确可预见的）**是不推荐的，异常的设计初衷是用来处理意外的、不可预见的错误，而不是作为正常业务逻辑的分支判断。

内容的提问来源于stack exchange，提问作者Sreekanth Karumanaghat