[jdk源码]Object

简介: [jdk源码]Object

Ojbect是java中所有类的根类,其他所有的类都是它的子类,包括数组等的这些,都继承了Object类。


方法


Object里共明文写了12个方法


  1. registerNatives()


registerNatives函数前面有native关键字修饰,Java中,用native关键字修饰的函数表明该方法的实现并不是在Java中去完成,而是由C/C++去完成,并被编译成了.dll,由Java去调用。方法的具体实现体在dll文件中,对于不同平台,其具体实现应该有所不同。用native修饰,即表示操作系统,需要提供此方法,Java本身需要使用。具体到registerNatives()方法本身,其主要作用是将C/C++中的方法映射到Java中的native方法,实现方法命名的解耦。


  1. getClass()


getClass也是一个native方法,返回的是此Object对象的类对象/运行时对象。效果与Object.class相同


  1. hashCode


hashCode也是一个native方法,调用这个方法将会返回该对象的哈希码值。


  • 两个对象equals的话,hashcode必然相等,反之不成立


  • 一次运行期间,同一个对象的hashcode相等,不同的执行期间,同一个对象的hashcode不必相等。


  1. equals(Object obj)


equals经常与 == 进行比较,在Object类中,equals的实现正是 ==,equals就是为了对比两个对象是否相等,而这个判断的标准,在Object中,就是 == ,其他的类也可以对这个方法进行重写,去实现自己的标尺。


  1. clone


clone也是一个native方法,它不是由java实现,clone函数返回的是一个引用,指向的是新的clone出来的对象,此对象与原对象分别占用不同的堆空间。


  1. toString()


toString方法也是一个我们经常使用的方法。需要注意的是,即使没有显式调用,但当我们使用System.out.println(obj)时,其内部也是通过toString()来实现的。Object类中,该方法会返回 “方法名@哈希值”


这是个经常被重写的方法。


  1. wait/notify/notifyAll


一说到wait(…) / notify() | notifyAll()几个方法,首先想到的是线程。确实,这几个方法主要用于java多线程之间的协作。先具体看下这几个方法的主要含义:


wait():调用此方法所在的当前线程等待,直到在其他线程上调用此方法的主调(某一对象)的notify()/notifyAll()方法。


wait(long timeout)/wait(long timeout, int nanos):调用此方法所在的当前线程等待,直到在其他线程上调用此方法的主调(某一对象)的notisfy()/notisfyAll()方法,或超过指定的超时时间量。


notify()/notifyAll():唤醒在此对象监视器上等待的单个线程/所有线程。


它们都是native方法,不是由java完成。


  1. finalize()


我们发现Object类中finalize方法被定义成一个空方法,为什么要如此定义呢?finalize方法的调用时机是怎么样的呢?


首先,Object中定义finalize方法表明Java中每一个对象都将具有finalize这种行为,其具体调用时机在:JVM准备对此对形象所占用的内存空间进行垃圾回收前,将被调用。由此可以看出,此方法并不是由我们主动去调用的(虽然可以主动去调用,此时与其他自定义方法无异)。


总结


Object作为基类,它所拥有的方法使所有其他对象的基本方法。Object类位于java.lang包中,java.lang包包含着Java最基础和核心的类,在编译时会自动导入。Object类没有定义属性,一共有13个方法(构造函数)。


目录
相关文章
|
6月前
|
安全 前端开发 Java
JDK源码级别彻底剖析JVM类加载机制
JDK源码级别彻底剖析JVM类加载机制
|
6月前
|
缓存 Dubbo Java
趁同事上厕所的时间,看完了 Dubbo SPI 的源码,瞬间觉得 JDK SPI 不香了
趁同事上厕所的时间,看完了 Dubbo SPI 的源码,瞬间觉得 JDK SPI 不香了
|
3月前
|
算法 安全 Java
深入JDK源码:揭开ConcurrentHashMap底层结构的神秘面纱
【8月更文挑战第24天】`ConcurrentHashMap`是Java并发编程中不可或缺的线程安全哈希表实现。它通过精巧的锁机制和无锁算法显著提升了并发性能。本文首先介绍了早期版本中使用的“段”结构,每个段是一个带有独立锁的小型哈希表,能够减少线程间竞争并支持动态扩容以应对高并发场景。随后探讨了JDK 8的重大改进:取消段的概念,采用更细粒度的锁控制,并引入`Node`等内部类以及CAS操作,有效解决了哈希冲突并实现了高性能的并发访问。这些设计使得`ConcurrentHashMap`成为构建高效多线程应用的强大工具。
52 2
|
5月前
|
Java Spring
深入解析Spring源码,揭示JDK动态代理的工作原理。
深入解析Spring源码,揭示JDK动态代理的工作原理。
58 0
|
6月前
|
设计模式 Java
根据JDK源码Calendar来看工厂模式和建造者模式
根据JDK源码Calendar来看工厂模式和建造者模式
|
6月前
|
算法 Java 索引
【数据结构与算法】4、双向链表(学习 jdk 的 LinkedList 部分源码)
【数据结构与算法】4、双向链表(学习 jdk 的 LinkedList 部分源码)
67 0
|
6月前
|
Java Linux iOS开发
Spring5源码(27)-静态代理模式和JDK、CGLIB动态代理
Spring5源码(27)-静态代理模式和JDK、CGLIB动态代理
48 0
|
6月前
|
消息中间件 Oracle Dubbo
Netty 源码共读(一)如何阅读JDK下sun包的源码
Netty 源码共读(一)如何阅读JDK下sun包的源码
127 1
|
6月前
|
算法 安全 Java
ConcurrentLinkedQueue的源码解析(基于JDK1.8)
ConcurrentLinkedQueue的源码解析(基于JDK1.8) ConcurrentLinkedQueue是Java集合框架中的一种线程安全的队列,它是通过CAS(Compare and Swap)算法实现的并发队列。在并发场景下,ConcurrentLinkedQueue能够保证队列的线程安全性,同时性能也很不错。
|
6月前
|
Java
LinkedBlockingDeque的源码解析(基于JDK1.8)
LinkedBlockingDeque的源码解析(基于JDK1.8) LinkedBlockingDeque是Java中的一个阻塞双端队列,它继承自AbstractQueue类并实现了BlockingDeque接口。在多线程环境下,LinkedBlockingDeque能够提供高效的并发访问能力。下面我们来看一下它的源码实现。

热门文章

最新文章