Object

方法：

hashCode()：默认情况下，对象的哈希码是通过将该对象的内部地址转换成一个整数来实现的。(取值极快，jvm对象头)
equals：比较两个对象是否相等（比较 2 个对象的引用是否相同）。
toString()：对象的名字 @ hashCode 的 16 进制。
notify()： final 修饰。唤醒一个在此对象监视器上等待的线程。
wait()： final 修饰。 放弃监视器（锁）并进入阻塞状态，直到其他线程持有获
得执行权，并持有了相同的监视器（锁）并调用 notify 为止。
finalize()：当 JVM 进行垃圾回收时触发。

wait 为什么被建议放在一个 while 循环里？
wait 前会释放监视器，被唤醒后又要重新获取，这瞬间可能有其他线程刚好
先获取到了监视器，从而导致状态发生了变化， 这时候用 while 循环来再判断
一下条件（比如队列是否为空）来避免不必要或有问题的操作。 这种机制还可
以用来处理伪唤醒（spurious wakeup），所谓伪唤醒就是 no reason wakeup。
自旋的好处是线程不需要睡眠和唤醒，减小了系统调用的开销。
wait/notify 与 monitor 关系：
1． wait 调用之前，必须获取到 monitor；
2． 调用 wait 后，会释放掉 monitor；
3． 调用 notify 之前，必须获取到 monitor；
4． 调用 notify 后要手动释放掉 monitor；
5． 当 wait 被唤醒后，会自动获取 monitor。
6． 如果主线程终止（执行完成） 了，也会释放掉 monitor。
hashCode()返回值与 equals()关系：
1． equals()相等，那么 hashCode()一定是相等的；
2． hashCode()相等， equals()不一定相等。
因此， 改写 equals()时，总是要改写 hashCode()。
关于 finalize()：
尽管 finalize 在某些时候是有用的，但是在大部分情况下，还是不建议使用，
基于以下几点：
1． 不保证会被 jvm 执行，且不知道何时才会执行。这就给程序执行带来了
很大不确定性。
2． 不同的 jvm 垃圾回收算法不一致，在一个 jvm 上工作良好，可能在另一
个 jvm 上未必有效。
3． 性能。根据 Joshua Bloch 在《Effective Java》中的描述，增加了 finalize 后，
对象的创建和销毁时间慢了 430 倍。
在什么情况下会重写 hashCode()和 equals()?
不被重写（原生）的 equals 方法是严格判断一个对象是否相等的方法（object1
== object2）。在我们的业务系统中判断对象时有时候需要的不是一种严格意义上
的相等，而是一种业务上的对象相等。

---

if (p.hash == hash && ((k = p.key) == key || (key != null && key.equals(k))))

---