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 是一个空白的接口如下：
那他作用只有一个， 他只是一个标记类用于判断对象是否可以被克隆（设计jdk的大佬们为什么这么做呢？有谁知道么？）public interface Cloneable { }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 性能问题
- 没有任何调用顺序保证，与对象死亡时间没关系