有趣的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 性能问题
  • 没有任何调用顺序保证,与对象死亡时间没关系

你可能感兴趣的:(有趣的JDK,Object源码)