类加载器之间的关系
本次我们主要讨论子类和父类的类加载器之前的关系, 以及包含之前的类加载器关系。
我们自定义一个classloder,设置父加载器为null,这样保证都是自己来加载,指向的路径和AppClassloader一致,这样方便2个都好直接加载
本次我们主要讨论子类和父类的类加载器之前的关系, 以及包含之前的类加载器关系。
我们自定义一个classloder,设置父加载器为null,这样保证都是自己来加载,指向的路径和AppClassloader一致,这样方便2个都好直接加载
下面的代码会不会导致Student类的加载与初始化?
1 | public class ClassLoadTest { |
当然你可以说通过JOL查看对象的头信息,当然那个也是一种方法,但那个只能说明是这种状态,没有过程,本次主要结合来验证,Synchronized 关键字锁的状态:无锁、偏向锁、轻量级锁、重量级锁
基于Ubuntu16测试成功。18测试失败,centos没有测试
主要是在Java调用系统函数的时候,打印log。但是在Java里面打印线程ID是JVM层面的。需要自己实现一个native方法,在java层面调用。最后对比对应的PID 和TID,发现查看当前线程调用了几次系统锁
Java 的重量级级锁都是通过glibc库的pthread_mutex_lock函数实现的,是在和操作系统级别的锁。
所有的JVM实现都必须实现这些参数的功能,而且向后兼容;
默认jvm实现这些参数的功能,但是并不保证所有jvm实现都满足,且不保证向后兼容;
此类参数各个jvm实现会有所不同,将来可能会随时取消,需要慎重使用;
pthread 库中有一个 pthread_self() 接口用来获取线程 ID,但是这个 ID并不是内核中那个线程 ID,pthread_t 到底是个什么样的数据结构呢?因为 POSIX 标准并没有限制 pthread_t 的数据类型,所以该类型取决于具体实现。对于 Linux 目前使用的 NPTL 实现而言,pthread_t 类型的线程 ID,本质上就是一个进程地址空间上的一个地址,而且 pthread_t 类型的线程 ID很有可能被复用。进程之间不会存在重复的线程 ID,而且不同线程之间也不会重复,在任意时刻都是全局唯一的值。
cglib是基于继承的代理的,但是final修饰的类的方法不能被代理,毕竟虚拟机规范限定了final关键字,想要实现代理的功能,自己不要加上final就是了。但是现在别人写好了库里的类,不方便修改想要尝试。
1 | public class Main{ |