Java &&；在if（）中

我想知道这两种代码在性能上有什么不同

String sample="hello";
    if(sample!=null)
    {
       if(!sample.equals(""))
        {
            // some code in here
         }
    }

或

据我所知，在第一个代码中，如果sample不是null，那么只有它才会进入块。第二段代码的情况也是如此。

---

我想知道的是，在性能或更好的编码标准方面有什么区别？为什么？

如果您询问性能，您应该始终进行测量。但不，应该没有区别。此外，如果这是您唯一的性能问题代码，那么我真的很羡慕您

至于编码标准。更少的嵌套几乎总是更好地阅读和遵循。这意味着如果将两者放在同一个

中，尤其是因为它们是相关的，则更可取。模式

if (check_foo_for_null && compare_foo)

非常常见，因此比另一个嵌套的
if
要少得多

编辑：要备份：

我有两个小方法：

static boolean x(String a) {
    if (a != null && a.equals("Foo"))
        return true;
    else return false;
}

static boolean y(String a) {
    if (a != null) {
        if (a.equals("Foo")) {
            return true;
        } else return false;
    } else return false;
}

生成以下代码：

  static boolean x(java.lang.String);
    Code:
       0: aload_0       
       1: ifnull        15
       4: aload_0       
       5: ldc           #16                 // String Foo
       7: invokevirtual #21                 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
      10: ifeq          15
      13: iconst_1      
      14: ireturn       
      15: iconst_0      
      16: ireturn       

  static boolean y(java.lang.String);
    Code:
       0: aload_0       
       1: ifnull        17
       4: aload_0       
       5: ldc           #16                 // String Foo
       7: invokevirtual #21                 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
      10: ifeq          15
      13: iconst_1      
      14: ireturn       
      15: iconst_0      
      16: ireturn       
      17: iconst_0      
      18: ireturn       

因此，除了一个无关的
else
跳转目标之外，代码是相同的。如果您甚至没有
else
：

static boolean z(String a) {
    if (a != null) {
        if (a.equals("Foo"))
            return true;
    return false;
}

那么结果其实是一样的：

  static boolean z(java.lang.String);
    Code:
       0: aload_0       
       1: ifnull        15
       4: aload_0       
       5: ldc           #16                 // String Foo
       7: invokevirtual #21                 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
      10: ifeq          15
      13: iconst_1      
      14: ireturn       
      15: iconst_0      
      16: ireturn       

如果你问的是绩效，你应该经常衡量。但不，应该没有区别。此外，如果这是您唯一的性能问题代码，那么我真的很羡慕您

至于编码标准。更少的嵌套几乎总是更好地阅读和遵循。这意味着如果将两者放在同一个
中，尤其是因为它们是相关的，则更可取。模式

if (check_foo_for_null && compare_foo)

非常常见，因此比另一个嵌套的
if
要少得多

编辑：要备份：

我有两个小方法：

static boolean x(String a) {
    if (a != null && a.equals("Foo"))
        return true;
    else return false;
}

static boolean y(String a) {
    if (a != null) {
        if (a.equals("Foo")) {
            return true;
        } else return false;
    } else return false;
}

生成以下代码：

  static boolean x(java.lang.String);
    Code:
       0: aload_0       
       1: ifnull        15
       4: aload_0       
       5: ldc           #16                 // String Foo
       7: invokevirtual #21                 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
      10: ifeq          15
      13: iconst_1      
      14: ireturn       
      15: iconst_0      
      16: ireturn       

  static boolean y(java.lang.String);
    Code:
       0: aload_0       
       1: ifnull        17
       4: aload_0       
       5: ldc           #16                 // String Foo
       7: invokevirtual #21                 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
      10: ifeq          15
      13: iconst_1      
      14: ireturn       
      15: iconst_0      
      16: ireturn       
      17: iconst_0      
      18: ireturn       

因此，除了一个无关的
else
跳转目标之外，代码是相同的。如果您甚至没有
else
：

static boolean z(String a) {
    if (a != null) {
        if (a.equals("Foo"))
            return true;
    return false;
}

那么结果其实是一样的：

  static boolean z(java.lang.String);
    Code:
       0: aload_0       
       1: ifnull        15
       4: aload_0       
       5: ldc           #16                 // String Foo
       7: invokevirtual #21                 // Method java/lang/String.equals:(Ljava/lang/Object;)Z
      10: ifeq          15
      13: iconst_1      
      14: ireturn       
      15: iconst_0      
      16: ireturn       

最有可能生成的
bytcode
将优化为
if（sample！=null&&！sample.equals（“”）
，因为
java
在编译时执行优化

如果您谈论的是您编写的实际代码，那么最好只有一个
If
。因为两个
if
的结构对于编译器来说更复杂（没有优化）。虽然我没有经验数据支持这一点。
最有可能生成的
字节码将被优化为
如果（sample！=null&&！sample.equals（“”）
，因为
java
在编译时执行优化

如果您谈论的是您编写的实际代码，那么最好只有一个
If
。因为两个
if
的结构对于编译器来说更复杂（没有优化）。虽然我没有经验数据支持这一点。
两者在性能方面没有差异。因为在第一种情况下，它检查一个条件，如果失败，它不会进入内部。在第二种情况下，JVM也会检查第一个条件，如果返回false，JVM将永远不会进行第二次检查。As逻辑&&运算符将始终false，如果first为false

就编码标准而言，我将选择第二个选项，因为它的编码行数较少。
两者在性能方面没有差异。因为在第一种情况下，它检查一个条件，如果失败，它不会进入内部。在第二种情况下，JVM也会检查第一个条件，如果返回false，JVM将永远不会进行第二次检查。As逻辑&&运算符将始终false，如果first为false

就编码标准而言，我将选择第二个选项，因为它的编码行数较少。
正如其他人所说，性能应该没有任何差异。
Small-tip-equals几乎总是调用instanceof，它为null返回false。
这样写：

if( !"".equals(foo)) {...}

执行相同的检查，并且是空安全的。
正如其他人所说，性能应该没有任何差异。
Small-tip-equals几乎总是调用instanceof，它为null返回false。
这样写：

if( !"".equals(foo)) {...}

执行相同的检查，并且是空安全的。
从我的观点来看，这没有什么区别。我发现第二个更易于阅读编译的代码可能是相同的。使您的代码可读，并在遇到真正的性能问题后担心微观优化。当sample不为null且不是空字符串时，这两个代码的行为不同。除非您的控制流可以将方法保留在内部
if
中，而外部
if
后面的代码只是某种回退，否则这两种实现具有不同的功能。我认为，这没有什么区别。我发现第二种方法更易于阅读。编译后的代码可能是相同的。使您的代码可读，并在遇到真正的性能问题后担心微观优化。当sample不为null且不是空字符串时，这两个代码的行为不同。除非控制流可以将方法保留在内部
if
中，而外部
if
后面的代码只是某种回退，否则这两种实现具有不同的功能。Java编译器速度很快。您不必再担心一行代码了。也就是说，几千个代码行，答案是说明，而不是实际评估4行代码的性能，现代编译器的复杂性在大多数情况下是一个愚蠢的问题（当然，在C++中保存十二个<代码>包含< /代码> s可能是另一回事，当然。如果这是唯一的原因，我会说这是没有意义的。Java编译器速度很快。您不必再担心一行代码了。答案是说明而不是实际评估4行代码的性能。现代编译器的复杂性在大多数情况下都是一件愚蠢的事情（节省了一打代码）