有趣的JDK，Object源码

JDK Object

主要方法 十个

1、native registerNatives

一个本地方法openJdk1.8 源码如下

static JNINativeMethod methods[] = {
    {"hashCode",    "()I",                    (void *)&JVM_IHashCode},
    {"wait",        "(J)V",                   (void *)&JVM_MonitorWait},
    {"notify",      "()V",                    (void *)&JVM_MonitorNotify},
    {"notifyAll",   "()V",                    (void *)&JVM_MonitorNotifyAll},
    {"clone",       "()Ljava/lang/Object;",   (void *)&JVM_Clone},
};

JNIEXPORT void JNICALL
Java_java_lang_Object_registerNatives(JNIEnv *env, jclass cls)
{
    (*env)->RegisterNatives(env, cls,
                            methods, sizeof(methods)/sizeof(methods[0]));
}

可以理解为：它是将Java层的方法名和本地函数对应起来，方便执行引擎在执行字节码时根据这些对应关系表来调用C/C++函数
static JNINativeMethod methods[] 就是函数对照表

2、native getClass

本地final 方法
返回此对象的运行时类，对应java中的 java.lang.Class 类

3、equals

public boolean equals(Object obj) {
      return (this == obj);
}

object的 equals, 一个常用的方法没什么特别的，直接比较内存地址，值得注意的是
如果要重写equals 的话, 记得要一起重写 hashCode方法，因为要满足 equals 相等的两个对象 hashCode 值一定相等 这是来自官方的约定

4、native hashCode

 public native int hashCode();

一个本地方法，可重写

5、clone()

protected native Object clone() throws CloneNotSupportedException;

又是一个本地方法，它负责克隆一个自己并返回给调用者。值得注意的是：

• 如果被克隆的类没有继承 java.lang.Cloneable 接口，会抛出 CloneNotSupportedException 异
  CloneNotSupportedException 是一个空白的接口如下：

  public interface Cloneable {
  }
  

  那他作用只有一个， 他只是一个标记类用于判断对象是否可以被克隆（设计jdk的大佬们为什么这么做呢？有谁知道么？）
• clone 方法默认只是浅拷贝什么是浅拷贝？
  clone方法不会clone对象内成员变量。要实现深拷贝， 需要我们自己重写 clone方法

6、toString

又是一个比较常用的方法，我们常常需要将一个类转换成字符形式打印出来，如下面这段代码 System.out.println 程序会自动调用 Object 和 HashMap 的toString方法。
那么执行这段代码我们会得到什么结果呢？

  1 System.out.println("1:" + new Object());

  2 Map data = new HashMap<>();
  3 data.put("k", "v");
  4 System.out.println("2:" + data);

程序执行 效果如下：

1:java.lang.Object@543e710e
2:{k=v}

我们分别得到了一串乱七八糟的字符，和比较合理的字符。
因为Object的toString 源码为：

    public String toString() {
        // 规则 包路径 + @ + hashcode 的十六进制字符
        return getClass().getName() + "@" + Integer.toHexString(hashCode());
    }
    
    /**  
    * Integer.toHexString 将十进制转为十六进制
    * 忽略具体实现
    **/
    public static String toHexString(int i) {
      return toUnsignedString0(i, 4);
    }
    
    

8、notify() notifyAll() 都是 native 本地方法

• 作用类似。唤醒等待该对象释放锁的线程，notifyAll 方法是唤醒所有等待该对象释放锁的线程
• 未持有锁的状态下调用该方法,会抛出异常 IllegalMonitorStateException
• 一般与 wait 方法配合使用
• 不建议在开发中使用这一系列方法，会让你的代码可读性变得非常差
• 调用notify之后不会立刻释放锁，会继续执行，当走出同步区域释放锁之后才回去唤醒等待中的线程

9、wait() wait(long timeout) wait(long timeout, int nanos)

• 持有锁的对象调用将立刻释放锁，并立刻进入阻塞状态，等待notify方法唤醒
• 唤醒之后要重新参与锁竞争
• wait(long timeout) wait(long timeout, int nanos) 的参数是超时时间，等待超过这个时间之后，程序会自动唤醒。
  timeout(毫秒) nanos(微妙)
• wait()无参方法，没有外界唤醒的话 会一直等待下去！
• 未持有锁的状态下调用该方法,会抛出异常 IllegalMonitorStateException

10、finalize()

非常鸡肋的一个方法，不建议使用

protected void finalize() throws Throwable { }

• 垃圾回收器回收一个待回收对象之前，会调用一次这个方法。前提是这个对象有重写finalize()

有什么用呢？

• 回收之前通知程序，程序可以利用 finalize 方法回收一些资源，也可以进行一次自救（不希望被回收）

// 拯救自己 《伪代码》
protected void finalize() throws Throwable { 
    某全局静态变量.value = this; // 自我拯救 完成，这样垃圾回收器本次将不会回收我
}

• 但是要注意，对象只能复活一次；在垃圾回收过程中，不能对复活对象调用 Finalize。垃圾回收发现一个待回收对象是 复活对象时会直接回收

为什么不建议使用呢？

• 不及时，没有 try finally 及时，要等垃圾回收前才调用，看GC心情
• 增加垃圾回回收过程的复杂度，降低垃圾收集器效率。大量使用可能引起 jvm 性能问题
• 没有任何调用顺序保证，与对象死亡时间没关系