两个Long类型真的不能直接用>或<比较么？其实能够

时间 2019-12-23

标签两个 long 类型不能直接比较其实能够繁體版

原文原文链接

　　当我在Google输入“Long类型的比较”时，会出现多如牛毛的与这个问题相关的博文，而且这些博文对此问题的见解一模一样，都“不约而同”地持有以下观点：java

对于Long类型的数据，它是一个对象，因此对象不能够直接经过“>”，“==”，“<”的比较。若要比较是否相等，能够用Long对象的equals方法；若要进行“>”，“<”的比较，需经过Long对象的longValue方法。app

那么问题来了，这个观点真的全对吗？或者准确地说，后半段关于“>”，“<”的说法真的对吗？起初我也差点信了，按理说Java中并无像C++中的操做符重载之类的东东，对象直接拿来用“>”或“<”比较确实不多这么干的，并且有童鞋可能会说，既然你们都这么说，固然是对的无疑咯。那么今天笔者想告诉你的是，它是错的！Long类型能够直接用“>”和“<”比较，而且其余包装类型也同理。不信？先别急着反驳，且听笔者娓娓道来。ide

问题起源

　　关于Long类型的大小比较这个问题，实际上是源于个人上一篇博文谈谈ali与Google的Java开发规范，在其中关于“相同类型的包装类对象之间值的比较”这一规范，我补充了以下一点：单元测试

　　而后oschina上的一个热心网友关于此提出了一个很好的问题：测试

　　即有没有可能比较的是内存地址而且恰好其大小知足上述条件？想一想也不无道理，毕竟对于Java中的对象引用a、b、c的值实际就是对象在堆中的地址。关于这个问题，其实我最初也质疑过，为此我编写了多种相似上面的testCase，好比：ui

Long a = new Long(1000L);
Long b = new Long(2000L);
Long c = new Long(222L);
Assert.isTrue(a<b && a>c);	//断言成功

　　最终的结论跟预期一致的：二者的比较结果跟Long对象中的数值大小的比较结果是一致的，至少从目前所尝试过的全部testCase来看是这样的。google

从现象到本质

　　可是，光靠那几个有限的单元测试，貌似并不具备较强的说服力，心中不免总有疑惑：会不会有特殊的case没覆盖到？会不会仍是地址比较的巧合？怎么才能有效地验证个人结论呢？编码

　　因而我开始琢磨：毕竟对于new Long()这种操做，是在堆中动态分配内存的，咱们不太好控制a、b等的地址大小，那又该怎么验证上述的比较不是地址比较的结果呢？除了地址以外，还有别的咱们能控制的吗？有的，那就是对象中的内容！咱们能够在不改变对象引用值的状况下，改变对象的内容，而后看其比较结果是否发生变化，这对于咱们来讲垂手可得。有时候换个角度思考问题，就能有新的收获！debug

1、debug验证

　　那么接下来，咱们就能够用反证法来证实上述问题，仍是以本文开头的testCase为例：假设上述testCase中比较的是地址值，只要咱们不对a、b进行赋值操做，即不改变它们的地址值，其比较结果就应该也是始终不变，此时咱们仅修改对象中的数值，这里对应Long对象中的value字段，使数值的大小比较与当前Long对象的比较结果相反，若是此时Long对象的比较结果也跟着变为相反，也就推翻了地址比较这一假设，不然就是地址比较，证毕。code

　　接下来以实例来演示咱们的推断过程。首先上代码：

/**
 * @author sherlockyb
 * @2018年1月14日
 */
public class JdkTest {

  @Test
  public void longCompare() {
    Long a = new Long(1000L);
    Long b = new Long(222L);

    boolean flagBeforeAlter = a > b;
    boolean flagAfterAlter = a > b; // 断点1

    System.out.println("flagBeforeAlter: " + flagBeforeAlter
        + ", flagAfterAlter: " + flagAfterAlter); // 断点2
  }
}

　　咱们以debug模式运行上述testCase，首先运行到断点1处，此处可观察到flagBeforeAlter的当前值为true：

　　此时咱们经过Change Value修改a中的value值为100L，如图：

　　而后F8到断点2，观察此时flagAfterAlter的值为false：

　　最后的输出结果以下：

flagBeforeAlter: true, flagAfterAlter: false

　　由此说明，两个Long对象直接用“>”或“<”比较时，是数值比较而非地址比较。

　　好了，上面的debug测试已经能解释咱们的困惑，可是笔者认为这还不够！仅仅停留在表面不是咱们程序猿的做风，咱们要从本质——源码出发。原理是什么？为何最终比较的是数值而不是引用？难道这也发生了自动拆箱吗？（跟咱们之前所认知的自动拆箱有出入哦）

2、回归本质——字节码

　　真理来自源码。咱们经过javap -c来看下刚才那个JdkTest类，反编译字节码是啥：

// Compiled from "JdkTest.java"
public class org.sherlockyb.blogdemos.jdk.JdkTest {
  public org.sherlockyb.blogdemos.jdk.JdkTest();
    Code:
       0: aload_0       
       1: invokespecial #8                  // Method java/lang/Object."<init>":()V
       4: return        

  public void longCompare();
    Code:
       0: new           #17                 // class java/lang/Long
       3: dup           
       4: ldc2_w        #19                 // long 1000l
       7: invokespecial #21                 // Method java/lang/Long."<init>":(J)V
      10: astore_1      
      11: new           #17                 // class java/lang/Long
      14: dup           
      15: ldc2_w        #24                 // long 222l
      18: invokespecial #21                 // Method java/lang/Long."<init>":(J)V
      21: astore_2      
      22: aload_1       
      23: invokevirtual #26                 // Method java/lang/Long.longValue:()J
      26: aload_2       
      27: invokevirtual #26                 // Method java/lang/Long.longValue:()J
      30: lcmp          
      31: ifle          38
      34: iconst_1      
      35: goto          39
      38: iconst_0      
      39: istore_3      
      40: aload_1       
      41: invokevirtual #26                 // Method java/lang/Long.longValue:()J
      44: aload_2       
      45: invokevirtual #26                 // Method java/lang/Long.longValue:()J
      48: lcmp          
      49: ifle          56
      52: iconst_1      
      53: goto          57
      56: iconst_0      
      57: istore        4
      59: getstatic     #30                 // Field java/lang/System.out:Ljava/io/PrintStream;
      62: new           #36                 // class java/lang/StringBuilder
      65: dup           
      66: ldc           #38                 // String flagBeforeAlter: 
      68: invokespecial #40                 // Method java/lang/StringBuilder."<init>":(Ljava/lang/String;)V
      71: iload_3       
      72: invokevirtual #43                 // Method java/lang/StringBuilder.append:(Z)Ljava/lang/StringBuilder;
      75: ldc           #47                 // String , flagAfterAlter: 
      77: invokevirtual #49                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
      80: iload         4
      82: invokevirtual #43                 // Method java/lang/StringBuilder.append:(Z)Ljava/lang/StringBuilder;
      85: invokevirtual #52                 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
      88: invokevirtual #56                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
      91: return        
}

　　第59行（这里的“行”是一种形象的描述，实指当前字节码相对于方法体开始位置的偏移量）是咱们打印结果的地方：System.out.println(...) 　　从字节码能够清晰地看到第23、27行以及第41、45行，invokevirtual，显式调用了java/lang/Long.longValue:()方法，确实自动拆箱了。也就是说对于基本包装类型，除了咱们以前所认知的自动装箱和拆箱场景（关于自动装箱和拆箱，你们能够参考这篇博文——Java中的自动装箱与拆箱，写的不错，这里我就不作过多叙述了）外，对于两个包装类型的>和<的操做，也会自动拆箱。无需任何testCase来佐证，结论一目了然。

　　除了Long类型，感兴趣的童鞋还能够找Integer、Byte、Short等来验证下，结果是同样的，这里我就不作过多叙述了。

总结

　　古人说得好——尽信书，则不如无书。可能，大多数的咱们在面对这个问题时，都会下意识地去Google一把，而后多家博客对比查阅，最后发现几乎全部的博文都是一致的观点：Long对象不可直接用">"或"<"比较，须要调用Long.longValue()来比较。因而毫无疑问地就信了。当再次遇到这个问题时，就会“很自信”地告诉别人，要用Long.longValue()比较。而实际呢，殊不知道本身已经陷入误区！

　　虽然今天谈论的只是Long对象的">"或"<"用法问题，看起来好像是个“小问题”，最坏状况下，若是不肯定是否能够直接比较，大不了直接用Long.longValue来比较，并不会阻碍你编码。可是，笔者想说可是，做为一个程序猿，打破砂锅问到底的精神是不可少的，咱们应该拒绝黑盒，追求细节，这样才可能更好地成长，在代码的世界里游刃有余。

同步更新到原文。