Java面试重要知识点
为什么 Java 中只有值传递?
开始之前,我们先来搞懂下面这两个概念:
- 形参&实参
- 值传递&引用传递
形参&实参
方法的定义可能会用到 参数(有参的方法),参数在程序语言中分为:
- 实参(实际参数) :用于传递给函数/方法的参数,必须有确定的值。
- 形参(形式参数) :用于定义函数/方法,接收实参,不需要有确定的值。
1 | String hello = "Hello!"; |
值传递&引用传递
程序设计语言将实参传递给方法(或函数)的方式分为两种:
- 值传递 :方法接收的是实参值的拷贝,会创建副本。
- 引用传递 :方法接收的直接是实参所引用的对象在堆中的地址,不会创建副本,对形参的修改将影响到实参。
很多程序设计语言(比如 C++、 Pascal )提供了两种参数传递的方式,不过,在 Java 中只有值传递。
为什么 Java 只有值传递?
为什么说 Java 只有值传递呢? 不需要太多废话,我通过 3 个例子来给大家证明。
案例1:传递基本类型参数
代码:
1 | public static void main(String[] args) { |
输出:
1 | a = 20 |
解析:
在 swap()
方法中,a
、b
的值进行交换,并不会影响到 num1
、num2
。因为,a
、b
的值,只是从 num1
、num2
的复制过来的。也就是说,a、b 相当于 num1
、num2
的副本,副本的内容无论怎么修改,都不会影响到原件本身。
通过上面例子,我们已经知道了一个方法不能修改一个基本数据类型的参数,而对象引用作为参数就不一样,请看案例2。
案例2:传递引用类型参数1
代码:
1 | public static void main(String[] args) { |
输出:
1 | 1 |
解析:
看了这个案例很多人肯定觉得 Java 对引用类型的参数采用的是引用传递。
实际上,并不是的,这里传递的还是值,不过,这个值是实参的地址罢了!
也就是说 change
方法的参数拷贝的是 arr
(实参)的地址,因此,它和 arr
指向的是同一个数组对象。这也就说明了为什么方法内部对形参的修改会影响到实参。
为了更强有力地反驳 Java 对引用类型的参数采用的不是引用传递,我们再来看下面这个案例!
案例3 :传递引用类型参数2
1 | public class Person { |
输出:
1 | person1:小李 |
解析:
怎么回事???两个引用类型的形参互换并没有影响实参啊!
swap
方法的参数 person1
和 person2
只是拷贝的实参 xiaoZhang
和 xiaoLi
的地址。因此, person1
和 person2
的互换只是拷贝的两个地址的互换罢了,并不会影响到实参 xiaoZhang
和 xiaoLi
。
总结
Java 中将实参传递给方法(或函数)的方式是 值传递 :
- 如果参数是基本类型的话,很简单,传递的就是基本类型的字面量值的拷贝,会创建副本。
- 如果参数是引用类型,传递的就是实参所引用的对象在堆中地址值的拷贝,同样也会创建副本。
Java 序列化详解
序列化和反序列化相关概念
#什么是序列化?什么是反序列化?
如果我们需要持久化 Java 对象比如将 Java 对象保存在文件中,或者在网络传输 Java 对象,这些场景都需要用到序列化。
简单来说:
- 序列化: 将数据结构或对象转换成二进制字节流的过程
- 反序列化:将在序列化过程中所生成的二进制字节流的过程转换成数据结构或者对象的过程
对于 Java 这种面向对象编程语言来说,我们序列化的都是对象(Object)也就是实例化后的类(Class),但是在 C++这种半面向对象的语言中,struct(结构体)定义的是数据结构类型,而 class 对应的是对象类型。
维基百科是如是介绍序列化的:
序列化(serialization)在计算机科学的数据处理中,是指将数据结构或对象状态转换成可取用格式(例如存成文件,存于缓冲,或经由网络中发送),以留待后续在相同或另一台计算机环境中,能恢复原先状态的过程。依照序列化格式重新获取字节的结果时,可以利用它来产生与原始对象相同语义的副本。对于许多对象,像是使用大量引用的复杂对象,这种序列化重建的过程并不容易。面向对象中的对象序列化,并不概括之前原始对象所关系的函数。这种过程也称为对象编组(marshalling)。从一系列字节提取数据结构的反向操作,是反序列化(也称为解编组、deserialization、unmarshalling)。
综上:序列化的主要目的是通过网络传输对象或者说是将对象存储到文件系统、数据库、内存中。
实际开发中有哪些用到序列化和反序列化的场景?
- 对象在进行网络传输(比如远程方法调用 RPC 的时候)之前需要先被序列化,接收到序列化的对象之后需要再进行反序列化;
- 将对象存储到文件中的时候需要进行序列化,将对象从文件中读取出来需要进行反序列化。
- 将对象存储到缓存数据库(如 Redis)时需要用到序列化,将对象从缓存数据库中读取出来需要反序列化。
#序列化协议对应于 TCP/IP 4 层模型的哪一层?
我们知道网络通信的双方必须要采用和遵守相同的协议。TCP/IP 四层模型是下面这样的,序列化协议属于哪一层呢?
- 应用层
- 传输层
- 网络层
- 网络接口层
如上图所示,OSI 七层协议模型中,表示层做的事情主要就是对应用层的用户数据进行处理转换为二进制流。反过来的话,就是将二进制流转换成应用层的用户数据。这不就对应的是序列化和反序列化么?
因为,OSI 七层协议模型中的应用层、表示层和会话层对应的都是 TCP/IP 四层模型中的应用层,所以序列化协议属于 TCP/IP 协议应用层的一部分。
常见序列化协议对比
JDK 自带的序列化方式一般不会用 ,因为序列化效率低并且部分版本有安全漏洞。比较常用的序列化协议有 hessian、kyro、protostuff。
下面提到的都是基于二进制的序列化协议,像 JSON 和 XML 这种属于文本类序列化方式。虽然 JSON 和 XML 可读性比较好,但是性能较差,一般不会选择。
JDK 自带的序列化方式
JDK 自带的序列化,只需实现 java.io.Serializable
接口即可。
1 |
|
序列化号 serialVersionUID 属于版本控制的作用。序列化的时候 serialVersionUID 也会被写入二级制序列,当反序列化时会检查 serialVersionUID 是否和当前类的 serialVersionUID 一致。如果 serialVersionUID 不一致则会抛出
InvalidClassException
异常。强烈推荐每个序列化类都手动指定其serialVersionUID
,如果不手动指定,那么编译器会动态生成默认的序列化号
我们很少或者说几乎不会直接使用这个序列化方式,主要原因有两个:
- 不支持跨语言调用 : 如果调用的是其他语言开发的服务的时候就不支持了。
- 性能差 :相比于其他序列化框架性能更低,主要原因是序列化之后的字节数组体积较大,导致传输成本加大。
Kryo
Kryo 是一个高性能的序列化/反序列化工具,由于其变长存储特性并使用了字节码生成机制,拥有较高的运行速度和较小的字节码体积。
另外,Kryo 已经是一种非常成熟的序列化实现了,已经在 Twitter、Groupon、Yahoo 以及多个著名开源项目(如 Hive、Storm)中广泛的使用。
guide-rpc-frameworkopen in new window 就是使用的 kyro 进行序列化,序列化和反序列化相关的代码如下:
1 | /** |
Protobuf
Protobuf 出自于 Google,性能还比较优秀,也支持多种语言,同时还是跨平台的。就是在使用中过于繁琐,因为你需要自己定义 IDL 文件和生成对应的序列化代码。这样虽然不然灵活,但是,另一方面导致 protobuf 没有序列化漏洞的风险。
Protobuf 包含序列化格式的定义、各种语言的库以及一个 IDL 编译器。正常情况下你需要定义 proto 文件,然后使用 IDL 编译器编译成你需要的语言
一个简单的 proto 文件如下:
1 | // protobuf的版本 |
ProtoStuff
由于 Protobuf 的易用性,它的哥哥 Protostuff 诞生了。
protostuff 基于 Google protobuf,但是提供了更多的功能和更简易的用法。虽然更加易用,但是不代表 ProtoStuff 性能更差。
hessian
hessian 是一个轻量级的,自定义描述的二进制 RPC 协议。hessian 是一个比较老的序列化实现了,并且同样也是跨语言的。
dubbo RPC 默认启用的序列化方式是 hessian2 ,但是,Dubbo 对 hessian2 进行了修改,不过大体结构还是差不多。
总结
Kryo 是专门针对 Java 语言序列化方式并且性能非常好,如果你的应用是专门针对 Java 语言的话可以考虑使用,并且 Dubbo 官网的一篇文章中提到说推荐使用 Kryo 作为生产环境的序列化方式。(文章地址:https://dubbo.apache.org/zh/docs/v2.7/user/references/protocol/rest/open in new window)
像 Protobuf、 ProtoStuff、hessian 这类都是跨语言的序列化方式,如果有跨语言需求的话可以考虑使用。
除了我上面介绍到的序列化方式的话,还有像 Thrift,Avro 这些。
Java 反射机制详解
何为反射?
如果说大家研究过框架的底层原理或者咱们自己写过框架的话,一定对反射这个概念不陌生。
反射之所以被称为框架的灵魂,主要是因为它赋予了我们在运行时分析类以及执行类中方法的能力。
通过反射你可以获取任意一个类的所有属性和方法,你还可以调用这些方法和属性。
反射的应用场景了解么?
像咱们平时大部分时候都是在写业务代码,很少会接触到直接使用反射机制的场景。
但是,这并不代表反射没有用。相反,正是因为反射,你才能这么轻松地使用各种框架。像 Spring/Spring Boot、MyBatis 等等框架中都大量使用了反射机制。
这些框架中也大量使用了动态代理,而动态代理的实现也依赖反射。
比如下面是通过 JDK 实现动态代理的示例代码,其中就使用了反射类 Method
来调用指定的方法。
1 | public class DebugInvocationHandler implements InvocationHandler { |
另外,像 Java 中的一大利器 注解 的实现也用到了反射。
为什么你使用 Spring 的时候 ,一个@Component
注解就声明了一个类为 Spring Bean 呢?为什么你通过一个 @Value
注解就读取到配置文件中的值呢?究竟是怎么起作用的呢?
这些都是因为你可以基于反射分析类,然后获取到类/属性/方法/方法的参数上的注解。你获取到注解之后,就可以做进一步的处理。
谈谈反射机制的优缺点
优点 : 可以让咱们的代码更加灵活、为各种框架提供开箱即用的功能提供了便利
缺点 :让我们在运行时有了分析操作类的能力,这同样也增加了安全问题。比如可以无视泛型参数的安全检查(泛型参数的安全检查发生在编译时)。另外,反射的性能也要稍差点,不过,对于框架来说实际是影响不大的。相关阅读:Java Reflection: Why is it so slow?open in new window
反射实战
获取 Class 对象的四种方式
如果我们动态获取到这些信息,我们需要依靠 Class 对象。Class 类对象将一个类的方法、变量等信息告诉运行的程序。Java 提供了四种方式获取 Class 对象:
1. 知道具体类的情况下可以使用:
1 | Class alunbarClass = TargetObject.class; |
但是我们一般是不知道具体类的,基本都是通过遍历包下面的类来获取 Class 对象,通过此方式获取 Class 对象不会进行初始化
2. 通过 Class.forName()传入类的全路径获取:
1 | Class alunbarClass1 = Class.forName("cn.javaguide.TargetObject"); |
3. 通过对象实例instance.getClass()获取:
1 | TargetObject o = new TargetObject(); |
4. 通过类加载器xxxClassLoader.loadClass()传入类路径获取:
1 | ClassLoader.getSystemClassLoader().loadClass("cn.javaguide.TargetObject"); |
通过类加载器获取 Class 对象不会进行初始化,意味着不进行包括初始化等一系列步骤,静态代码块和静态对象不会得到执行
反射的一些基本操作
- 创建一个我们要使用反射操作的类
TargetObject
。
1 | package cn.javaguide; |
- 使用反射操作这个类的方法以及参数
1 | package cn.javaguide; |
输出内容:
1 | publicMethod |
注意 : 有读者提到上面代码运行会抛出 ClassNotFoundException
异常,具体原因是你没有下面把这段代码的包名替换成自己创建的 TargetObject
所在的包 。
1 | Class<?> targetClass = Class.forName("cn.javaguide.TargetObject"); |
Java 代理模式详解
代理模式
代理模式是一种比较好理解的设计模式。简单来说就是 我们使用代理对象来代替对真实对象(real object)的访问,这样就可以在不修改原目标对象的前提下,提供额外的功能操作,扩展目标对象的功能。
代理模式的主要作用是扩展目标对象的功能,比如说在目标对象的某个方法执行前后你可以增加一些自定义的操作。
举个例子:新娘找来了自己的姨妈来代替自己处理新郎的提问,新娘收到的提问都是经过姨妈处理过滤之后的。姨妈在这里就可以看作是代理你的代理对象,代理的行为(方法)是接收和回复新郎的提问。
代理模式有静态代理和动态代理两种实现方式,我们 先来看一下静态代理模式的实现。
静态代理
静态代理中,我们对目标对象的每个方法的增强都是手动完成的(后面会具体演示代码),非常不灵活(比如接口一旦新增加方法,目标对象和代理对象都要进行修改)且麻烦(需要对每个目标类都单独写一个代理类)。 实际应用场景非常非常少,日常开发几乎看不到使用静态代理的场景。
上面我们是从实现和应用角度来说的静态代理,从 JVM 层面来说, 静态代理在编译时就将接口、实现类、代理类这些都变成了一个个实际的 class 文件。
静态代理实现步骤:
- 定义一个接口及其实现类;
- 创建一个代理类同样实现这个接口
- 将目标对象注入进代理类,然后在代理类的对应方法调用目标类中的对应方法。这样的话,我们就可以通过代理类屏蔽对目标对象的访问,并且可以在目标方法执行前后做一些自己想做的事情。
下面通过代码展示!
1.定义发送短信的接口
1 | public interface SmsService { |
2.实现发送短信的接口
1 | public class SmsServiceImpl implements SmsService { |
3.创建代理类并同样实现发送短信的接口
1 | public class SmsProxy implements SmsService { |
4.实际使用
1 | public class Main { |
运行上述代码之后,控制台打印出:
1 | before method send() |
可以输出结果看出,我们已经增加了 SmsServiceImpl
的send()
方法。
动态代理
相比于静态代理来说,动态代理更加灵活。我们不需要针对每个目标类都单独创建一个代理类,并且也不需要我们必须实现接口,我们可以直接代理实现类( CGLIB 动态代理机制)。
从 JVM 角度来说,动态代理是在运行时动态生成类字节码,并加载到 JVM 中的。
说到动态代理,Spring AOP、RPC 框架应该是两个不得不提的,它们的实现都依赖了动态代理。
动态代理在我们日常开发中使用的相对较少,但是在框架中的几乎是必用的一门技术。学会了动态代理之后,对于我们理解和学习各种框架的原理也非常有帮助。
就 Java 来说,动态代理的实现方式有很多种,比如 JDK 动态代理、CGLIB 动态代理等等。
guide-rpc-frameworkopen in new window 使用的是 JDK 动态代理,我们先来看看 JDK 动态代理的使用。
另外,虽然 guide-rpc-frameworkopen in new window 没有用到 CGLIB 动态代理 ,我们这里还是简单介绍一下其使用以及和JDK 动态代理的对比。
JDK 动态代理机制
介绍
在 Java 动态代理机制中 InvocationHandler 接口和 Proxy 类是核心。
Proxy
类中使用频率最高的方法是:newProxyInstance()
,这个方法主要用来生成一个代理对象。
1 | public static Object newProxyInstance(ClassLoader loader, |
这个方法一共有 3 个参数:
- loader :类加载器,用于加载代理对象。
- interfaces : 被代理类实现的一些接口;
- h : 实现了
InvocationHandler
接口的对象;
要实现动态代理的话,还必须需要实现InvocationHandler
来自定义处理逻辑。 当我们的动态代理对象调用一个方法时,这个方法的调用就会被转发到实现InvocationHandler
接口类的 invoke
方法来调用。
1 | public interface InvocationHandler { |
invoke()
方法有下面三个参数:
- proxy :动态生成的代理类
- method : 与代理类对象调用的方法相对应
- args : 当前 method 方法的参数
也就是说:你通过Proxy 类的 newProxyInstance() 创建的代理对象在调用方法的时候,实际会调用到实现InvocationHandler 接口的类的 invoke()方法。 你可以在 invoke()
方法中自定义处理逻辑,比如在方法执行前后做什么事情。
JDK 动态代理类使用步骤
- 定义一个接口及其实现类;
- 自定义
InvocationHandler
并重写invoke
方法,在invoke
方法中我们会调用原生方法(被代理类的方法)并自定义一些处理逻辑; - 通过
Proxy.newProxyInstance(ClassLoader loader,Class<?>[] interfaces,InvocationHandler h)
方法创建代理对象;
代码示例
这样说可能会有点空洞和难以理解,我上个例子,大家感受一下吧!
1.定义发送短信的接口
1 | public interface SmsService { |
2.实现发送短信的接口
1 | public class SmsServiceImpl implements SmsService { |
3.定义一个 JDK 动态代理类
1 | import java.lang.reflect.InvocationHandler; |
invoke()
方法: 当我们的动态代理对象调用原生方法的时候,最终实际上调用到的是 invoke()
方法,然后 invoke()
方法代替我们去调用了被代理对象的原生方法。
4.获取代理对象的工厂类
1 | public class JdkProxyFactory { |
getProxy()
:主要通过Proxy.newProxyInstance()
方法获取某个类的代理对象
5.实际使用
1 | SmsService smsService = (SmsService) JdkProxyFactory.getProxy(new SmsServiceImpl()); |
运行上述代码之后,控制台打印出:
1 | before method send |
CGLIB 动态代理机制
介绍
JDK 动态代理有一个最致命的问题是其只能代理实现了接口的类。
为了解决这个问题,我们可以用 CGLIB 动态代理机制来避免。
CGLIBopen in new window(Code Generation Library)是一个基于ASMopen in new window的字节码生成库,它允许我们在运行时对字节码进行修改和动态生成。CGLIB 通过继承方式实现代理。很多知名的开源框架都使用到了CGLIBopen in new window, 例如 Spring 中的 AOP 模块中:如果目标对象实现了接口,则默认采用 JDK 动态代理,否则采用 CGLIB 动态代理。
在 CGLIB 动态代理机制中 MethodInterceptor 接口和 Enhancer 类是核心。
你需要自定义 MethodInterceptor
并重写 intercept
方法,intercept
用于拦截增强被代理类的方法。
1 | public interface MethodInterceptor |
- obj : 动态生成的代理对象
- method : 被拦截的方法(需要增强的方法)
- args : 方法入参
- proxy : 用于调用原始方法
你可以通过 Enhancer
类来动态获取被代理类,当代理类调用方法的时候,实际调用的是 MethodInterceptor
中的 intercept
方法。
CGLIB 动态代理类使用步骤
- 定义一个类;
- 自定义
MethodInterceptor
并重写intercept
方法,intercept
用于拦截增强被代理类的方法,和 JDK 动态代理中的invoke
方法类似; - 通过
Enhancer
类的create()
创建代理类;
代码示例
不同于 JDK 动态代理不需要额外的依赖。CGLIBopen in new window(Code Generation Library) 实际是属于一个开源项目,如果你要使用它的话,需要手动添加相关依赖。
1 | <dependency> |
1.实现一个使用阿里云发送短信的类
1 | package github.javaguide.dynamicProxy.cglibDynamicProxy; |
2.自定义 MethodInterceptor(方法拦截器)
1 | import net.sf.cglib.proxy.MethodInterceptor; |
3.获取代理类
1 | import net.sf.cglib.proxy.Enhancer; |
4.实际使用
1 | AliSmsService aliSmsService = (AliSmsService) CglibProxyFactory.getProxy(AliSmsService.class); |
运行上述代码之后,控制台打印出:
1 | before method send |
JDK 动态代理和 CGLIB 动态代理对比
- JDK 动态代理只能代理实现了接口的类或者直接代理接口,而 CGLIB 可以代理未实现任何接口的类。 另外, CGLIB 动态代理是通过生成一个被代理类的子类来拦截被代理类的方法调用,因此不能代理声明为 final 类型的类和方法。
- 就二者的效率来说,大部分情况都是 JDK 动态代理更优秀,随着 JDK 版本的升级,这个优势更加明显。
静态代理和动态代理的对比
- 灵活性 :动态代理更加灵活,不需要必须实现接口,可以直接代理实现类,并且可以不需要针对每个目标类都创建一个代理类。另外,静态代理中,接口一旦新增加方法,目标对象和代理对象都要进行修改,这是非常麻烦的!
- JVM 层面 :静态代理在编译时就将接口、实现类、代理类这些都变成了一个个实际的 class 文件。而动态代理是在运行时动态生成类字节码,并加载到 JVM 中的。
总结
这篇文章中主要介绍了代理模式的两种实现:静态代理以及动态代理。涵盖了静态代理和动态代理实战、静态代理和动态代理的区别、JDK 动态代理和 Cglib 动态代理区别等内容。
文中涉及到的所有源码,你可以在这里找到:https://github.com/Snailclimb/guide-rpc-framework-learning/tree/master/src/main/java/github/javaguide/proxyopen in new window 。
BigDecimal 详解
《阿里巴巴 Java 开发手册》中提到:“为了避免精度丢失,可以使用 BigDecimal
来进行浮点数的运算”。
浮点数的运算竟然还会有精度丢失的风险吗?确实会!
示例代码:
1 | float a = 2.0f - 1.9f; |
为什么浮点数 float 或 double 运算的时候会有精度丢失的风险呢?
这个和计算机保存浮点数的机制有很大关系。我们知道计算机是二进制的,而且计算机在表示一个数字时,宽度是有限的,无限循环的小数存储在计算机时,只能被截断,所以就会导致小数精度发生损失的情况。这也就是解释了为什么浮点数没有办法用二进制精确表示。
就比如说十进制下的 0.2 就没办法精确转换成二进制小数:
1 | // 0.2 转换为二进制数的过程为,不断乘以 2,直到不存在小数为止, |
关于浮点数的更多内容,建议看一下计算机系统基础(四)浮点数open in new window这篇文章。
BigDecimal 介绍
BigDecimal
可以实现对浮点数的运算,不会造成精度丢失。
通常情况下,大部分需要浮点数精确运算结果的业务场景(比如涉及到钱的场景)都是通过 BigDecimal
来做的。
《阿里巴巴 Java 开发手册》中提到:浮点数之间的等值判断,基本数据类型不能用 == 来比较,包装数据类型不能用 equals 来判断。
具体原因我们在上面已经详细介绍了,这里就不多提了。
想要解决浮点数运算精度丢失这个问题,可以直接使用 BigDecimal
来定义浮点数的值,然后再进行浮点数的运算操作即可。
1 | BigDecimal a = new BigDecimal("1.0"); |
BigDecimal 常见方法
创建
我们在使用 BigDecimal
时,为了防止精度丢失,推荐使用它的BigDecimal(String val)
构造方法或者 BigDecimal.valueOf(double val)
静态方法来创建对象。
《阿里巴巴 Java 开发手册》对这部分内容也有提到,如下图所示。
加减乘除
add
方法用于将两个 BigDecimal
对象相加,subtract
方法用于将两个 BigDecimal
对象相减。multiply
方法用于将两个 BigDecimal
对象相乘,divide
方法用于将两个 BigDecimal
对象相除。
1 | BigDecimal a = new BigDecimal("1.0"); |
这里需要注意的是,在我们使用 divide
方法的时候尽量使用 3 个参数版本,并且RoundingMode
不要选择 UNNECESSARY
,否则很可能会遇到 ArithmeticException
(无法除尽出现无限循环小数的时候),其中 scale
表示要保留几位小数,roundingMode
代表保留规则。
1 | public BigDecimal divide(BigDecimal divisor, int scale, RoundingMode roundingMode) { |
保留规则非常多,这里列举几种:
1 | public enum RoundingMode { |
大小比较
a.compareTo(b)
: 返回 -1 表示 a
小于 b
,0 表示 a
等于 b
, 1 表示 a
大于 b
。
1 | BigDecimal a = new BigDecimal("1.0"); |
几位小数
通过 setScale
方法设置保留几位小数以及保留规则。保留规则有挺多种,不需要记,IDEA 会提示。
1 | BigDecimal m = new BigDecimal("1.255433"); |
BigDecimal 等值比较问题
《阿里巴巴 Java 开发手册》中提到:
BigDecimal
使用 equals()
方法进行等值比较出现问题的代码示例:
1 | BigDecimal a = new BigDecimal("1"); |
这是因为 equals()
方法不仅仅会比较值的大小(value)还会比较精度(scale),而 compareTo()
方法比较的时候会忽略精度。
1.0 的 scale 是 1,1 的 scale 是 0,因此 a.equals(b)
的结果是 false。
compareTo()
方法可以比较两个 BigDecimal
的值,如果相等就返回 0,如果第 1 个数比第 2 个数大则返回 1,反之返回-1。
1 | BigDecimal a = new BigDecimal("1"); |
BigDecimal 工具类分享
网上有一个使用人数比较多的 BigDecimal
工具类,提供了多个静态方法来简化 BigDecimal
的操作。
我对其进行了简单改进,分享一下源码:
1 | import java.math.BigDecimal; |
总结
浮点数没有办法用二进制精确表示,因此存在精度丢失的风险。
不过,Java 提供了BigDecimal
来操作浮点数。BigDecimal
的实现利用到了 BigInteger
(用来操作大整数), 所不同的是 BigDecimal
加入了小数位的概念。
Java 魔法类 Unsafe 详解
阅读过 JUC 源码的同学,一定会发现很多并发工具类都调用了一个叫做 Unsafe
的类。
那这个类主要是用来干什么的呢?有什么使用场景呢?这篇文章就带你搞清楚!
JUC是java.util.concurrent包的简称,在Java5.0添加,目的就是为了更好的支持高并发任务。让开发者进行多线程编程时减少竞争条件和死锁的问题!
Unsafe 介绍
Unsafe
是位于 sun.misc
包下的一个类,主要提供一些用于执行低级别、不安全操作的方法,如直接访问系统内存资源、自主管理内存资源等,这些方法在提升 Java 运行效率、增强 Java 语言底层资源操作能力方面起到了很大的作用。但由于 Unsafe
类使 Java 语言拥有了类似 C 语言指针一样操作内存空间的能力,这无疑也增加了程序发生相关指针问题的风险。在程序中过度、不正确使用 Unsafe
类会使得程序出错的概率变大,使得 Java 这种安全的语言变得不再“安全”,因此对 Unsafe
的使用一定要慎重。
另外,Unsafe
提供的这些功能的实现需要依赖本地方法(Native Method)。你可以将本地方法看作是 Java 中使用其他编程语言编写的方法。本地方法使用 native 关键字修饰,Java 代码中只是声明方法头,具体的实现则交给 本地代码。
为什么要使用本地方法呢?
- 需要用到 Java 中不具备的依赖于操作系统的特性,Java 在实现跨平台的同时要实现对底层的控制,需要借助其他语言发挥作用。
- 对于其他语言已经完成的一些现成功能,可以使用 Java 直接调用。
- 程序对时间敏感或对性能要求非常高时,有必要使用更加底层的语言,例如 C/C++甚至是汇编。
在 JUC 包的很多并发工具类在实现并发机制时,都调用了本地方法,通过它们打破了 Java 运行时的界限,能够接触到操作系统底层的某些功能。对于同一本地方法,不同的操作系统可能会通过不同的方式来实现,但是对于使用者来说是透明的,最终都会得到相同的结果。
Unsafe 创建
sun.misc.Unsafe
部分源码如下:
1 | public final class Unsafe { |
Unsafe
类为一单例实现,提供静态方法 getUnsafe
获取 Unsafe
实例。这个看上去貌似可以用来获取 Unsafe
实例。但是,当我们直接调用这个静态方法的时候,会抛出 SecurityException
异常:
1 | Exception in thread "main" java.lang.SecurityException: Unsafe |
为什么 public static 方法无法被直接调用呢?
这是因为在getUnsafe
方法中,会对调用者的classLoader
进行检查,判断当前类是否由Bootstrap classLoader
加载,如果不是的话那么就会抛出一个SecurityException
异常。也就是说,只有启动类加载器加载的类才能够调用 Unsafe 类中的方法,来防止这些方法在不可信的代码中被调用。
为什么要对 Unsafe 类进行这么谨慎的使用限制呢?
Unsafe
提供的功能过于底层(如直接访问系统内存资源、自主管理内存资源等),安全隐患也比较大,使用不当的话,很容易出现很严重的问题。
如若想使用 Unsafe 这个类的话,应该如何获取其实例呢?
这里介绍两个可行的方案。
1、利用反射获得 Unsafe 类中已经实例化完成的单例对象 theUnsafe
。
1 | private static Unsafe reflectGetUnsafe() { |
2、从getUnsafe
方法的使用限制条件出发,通过 Java 命令行命令-Xbootclasspath/a
把调用 Unsafe 相关方法的类 A 所在 jar 包路径追加到默认的 bootstrap 路径中,使得 A 被引导类加载器加载,从而通过Unsafe.getUnsafe
方法安全的获取 Unsafe 实例。
1 | java -Xbootclasspath/a: ${path} // 其中path为调用Unsafe相关方法的类所在jar包路径 |
Unsafe 功能
概括的来说,Unsafe
类实现功能可以被分为下面 8 类:
- 内存操作
- 内存屏障
- 对象操作
- 数据操作
- CAS 操作
- 线程调度
- Class 操作
- 系统信息
内存操作
介绍
如果你是一个写过 C 或者 C++ 的程序员,一定对内存操作不会陌生,而在 Java 中是不允许直接对内存进行操作的,对象内存的分配和回收都是由 JVM 自己实现的。但是在 Unsafe
中,提供的下列接口可以直接进行内存操作:
1 | //分配新的本地空间 |
使用下面的代码进行测试:
1 | private void memoryTest() { |
先看结果输出:
1 | addr: 2433733895744 |
分析一下运行结果,首先使用allocateMemory
方法申请 4 字节长度的内存空间,在循环中调用setMemory
方法向每个字节写入内容为byte
类型的 1,当使用 Unsafe 调用getInt
方法时,因为一个int
型变量占 4 个字节,会一次性读取 4 个字节,组成一个int
的值,对应的十进制结果为 16843009。
你可以通过下图理解这个过程:
在代码中调用reallocateMemory
方法重新分配了一块 8 字节长度的内存空间,通过比较addr
和addr3
可以看到和之前申请的内存地址是不同的。在代码中的第二个 for 循环里,调用copyMemory
方法进行了两次内存的拷贝,每次拷贝内存地址addr
开始的 4 个字节,分别拷贝到以addr3
和addr3+4
开始的内存空间上:
拷贝完成后,使用getLong
方法一次性读取 8 个字节,得到long
类型的值为 72340172838076673。
需要注意,通过这种方式分配的内存属于 堆外内存 ,是无法进行垃圾回收的,需要我们把这些内存当做一种资源去手动调用freeMemory
方法进行释放,否则会产生内存泄漏。通用的操作内存方式是在try
中执行对内存的操作,最终在finally
块中进行内存的释放。
为什么要使用堆外内存?
- 对垃圾回收停顿的改善。由于堆外内存是直接受操作系统管理而不是 JVM,所以当我们使用堆外内存时,即可保持较小的堆内内存规模。从而在 GC 时减少回收停顿对于应用的影响。
- 提升程序 I/O 操作的性能。通常在 I/O 通信过程中,会存在堆内内存到堆外内存的数据拷贝操作,对于需要频繁进行内存间数据拷贝且生命周期较短的暂存数据,都建议存储到堆外内存。
典型应用
DirectByteBuffer
是 Java 用于实现堆外内存的一个重要类,通常用在通信过程中做缓冲池,如在 Netty、MINA 等 NIO 框架中应用广泛。DirectByteBuffer
对于堆外内存的创建、使用、销毁等逻辑均由 Unsafe 提供的堆外内存 API 来实现。
下图为 DirectByteBuffer
构造函数,创建 DirectByteBuffer
的时候,通过 Unsafe.allocateMemory
分配内存、Unsafe.setMemory
进行内存初始化,而后构建 Cleaner
对象用于跟踪 DirectByteBuffer
对象的垃圾回收,以实现当 DirectByteBuffer
被垃圾回收时,分配的堆外内存一起被释放。
1 | DirectByteBuffer(int cap) { // package-private |
内存屏障
介绍
在介绍内存屏障前,需要知道编译器和 CPU 会在保证程序输出结果一致的情况下,会对代码进行重排序,从指令优化角度提升性能。而指令重排序可能会带来一个不好的结果,导致 CPU 的高速缓存和内存中数据的不一致,而内存屏障(Memory Barrier
)就是通过组织屏障两边的指令重排序从而避免编译器和硬件的不正确优化情况。
在硬件层面上,内存屏障是 CPU 为了防止代码进行重排序而提供的指令,不同的硬件平台上实现内存屏障的方法可能并不相同。在 Java8 中,引入了 3 个内存屏障的函数,它屏蔽了操作系统底层的差异,允许在代码中定义、并统一由 JVM 来生成内存屏障指令,来实现内存屏障的功能。
Unsafe
中提供了下面三个内存屏障相关方法:
1 | //内存屏障,禁止load操作重排序。屏障前的load操作不能被重排序到屏障后,屏障后的load操作不能被重排序到屏障前 |
内存屏障可以看做对内存随机访问的操作中的一个同步点,使得此点之前的所有读写操作都执行后才可以开始执行此点之后的操作。以loadFence
方法为例,它会禁止读操作重排序,保证在这个屏障之前的所有读操作都已经完成,并且将缓存数据设为无效,重新从主存中进行加载。
看到这估计很多小伙伴们会想到volatile
关键字了,如果在字段上添加了volatile
关键字,就能够实现字段在多线程下的可见性。基于读内存屏障,我们也能实现相同的功能。下面定义一个线程方法,在线程中去修改flag
标志位,注意这里的flag
是没有被volatile
修饰的:
1 |
|
在主线程的while
循环中,加入内存屏障,测试是否能够感知到flag
的修改变化:
1 | public static void main(String[] args){ |
运行结果:
1 | subThread change flag to:false |
而如果删掉上面代码中的loadFence
方法,那么主线程将无法感知到flag
发生的变化,会一直在while
中循环。可以用图来表示上面的过程:
了解 Java 内存模型(JMM
)的小伙伴们应该清楚,运行中的线程不是直接读取主内存中的变量的,只能操作自己工作内存中的变量,然后同步到主内存中,并且线程的工作内存是不能共享的。上面的图中的流程就是子线程借助于主内存,将修改后的结果同步给了主线程,进而修改主线程中的工作空间,跳出循环。
典型应用
在 Java 8 中引入了一种锁的新机制——StampedLock
,它可以看成是读写锁的一个改进版本。StampedLock
提供了一种乐观读锁的实现,这种乐观读锁类似于无锁的操作,完全不会阻塞写线程获取写锁,从而缓解读多写少时写线程“饥饿”现象。由于 StampedLock
提供的乐观读锁不阻塞写线程获取读锁,当线程共享变量从主内存 load 到线程工作内存时,会存在数据不一致问题。
为了解决这个问题,StampedLock
的 validate
方法会通过 Unsafe
的 loadFence
方法加入一个 load
内存屏障。
1 | public boolean validate(long stamp) { |
对象操作
介绍
对象属性
对象成员属性的内存偏移量获取,以及字段属性值的修改,在上面的例子中我们已经测试过了。除了前面的putInt
、getInt
方法外,Unsafe 提供了全部 8 种基础数据类型以及Object
的put
和get
方法,并且所有的put
方法都可以越过访问权限,直接修改内存中的数据。阅读 openJDK 源码中的注释发现,基础数据类型和Object
的读写稍有不同,基础数据类型是直接操作的属性值(value
),而Object
的操作则是基于引用值(reference value
)。下面是Object
的读写方法:
1 | //在对象的指定偏移地址获取一个对象引用 |
除了对象属性的普通读写外,Unsafe
还提供了 volatile 读写和有序写入方法。volatile
读写方法的覆盖范围与普通读写相同,包含了全部基础数据类型和Object
类型,以int
类型为例:
1 | //在对象的指定偏移地址处读取一个int值,支持volatile load语义 |
相对于普通读写来说,volatile
读写具有更高的成本,因为它需要保证可见性和有序性。在执行get
操作时,会强制从主存中获取属性值,在使用put
方法设置属性值时,会强制将值更新到主存中,从而保证这些变更对其他线程是可见的。
有序写入的方法有以下三个:
1 | public native void putOrderedObject(Object o, long offset, Object x); |
有序写入的成本相对volatile
较低,因为它只保证写入时的有序性,而不保证可见性,也就是一个线程写入的值不能保证其他线程立即可见。为了解决这里的差异性,需要对内存屏障的知识点再进一步进行补充,首先需要了解两个指令的概念:
Load
:将主内存中的数据拷贝到处理器的缓存中Store
:将处理器缓存的数据刷新到主内存中
顺序写入与volatile
写入的差别在于,在顺序写时加入的内存屏障类型为StoreStore
类型,而在volatile
写入时加入的内存屏障是StoreLoad
类型,如下图所示:
在有序写入方法中,使用的是StoreStore
屏障,该屏障确保Store1
立刻刷新数据到内存,这一操作先于Store2
以及后续的存储指令操作。而在volatile
写入中,使用的是StoreLoad
屏障,该屏障确保Store1
立刻刷新数据到内存,这一操作先于Load2
及后续的装载指令,并且,StoreLoad
屏障会使该屏障之前的所有内存访问指令,包括存储指令和访问指令全部完成之后,才执行该屏障之后的内存访问指令。
综上所述,在上面的三类写入方法中,在写入效率方面,按照put
、putOrder
、putVolatile
的顺序效率逐渐降低。
对象实例化
使用 Unsafe
的 allocateInstance
方法,允许我们使用非常规的方式进行对象的实例化,首先定义一个实体类,并且在构造函数中对其成员变量进行赋值操作:
1 |
|
分别基于构造函数、反射以及 Unsafe
方法的不同方式创建对象进行比较:
1 | public void objTest() throws Exception{ |
打印结果分别为 1、1、0,说明通过allocateInstance
方法创建对象过程中,不会调用类的构造方法。使用这种方式创建对象时,只用到了Class
对象,所以说如果想要跳过对象的初始化阶段或者跳过构造器的安全检查,就可以使用这种方法。在上面的例子中,如果将 A 类的构造函数改为private
类型,将无法通过构造函数和反射创建对象,但allocateInstance
方法仍然有效。
典型应用
- 常规对象实例化方式:我们通常所用到的创建对象的方式,从本质上来讲,都是通过 new 机制来实现对象的创建。但是,new 机制有个特点就是当类只提供有参的构造函数且无显示声明无参构造函数时,则必须使用有参构造函数进行对象构造,而使用有参构造函数时,必须传递相应个数的参数才能完成对象实例化。
- 非常规的实例化方式:而 Unsafe 中提供 allocateInstance 方法,仅通过 Class 对象就可以创建此类的实例对象,而且不需要调用其构造函数、初始化代码、JVM 安全检查等。它抑制修饰符检测,也就是即使构造器是 private 修饰的也能通过此方法实例化,只需提类对象即可创建相应的对象。由于这种特性,allocateInstance 在 java.lang.invoke、Objenesis(提供绕过类构造器的对象生成方式)、Gson(反序列化时用到)中都有相应的应用。
数组操作
介绍
arrayBaseOffset
与 arrayIndexScale
这两个方法配合起来使用,即可定位数组中每个元素在内存中的位置。
1 | //返回数组中第一个元素的偏移地址 |
典型应用
这两个与数据操作相关的方法,在 java.util.concurrent.atomic
包下的 AtomicIntegerArray
(可以实现对 Integer
数组中每个元素的原子性操作)中有典型的应用,如下图 AtomicIntegerArray
源码所示,通过 Unsafe
的 arrayBaseOffset
、arrayIndexScale
分别获取数组首元素的偏移地址 base
及单个元素大小因子 scale
。后续相关原子性操作,均依赖于这两个值进行数组中元素的定位,如下图二所示的 getAndAdd
方法即通过 checkedByteOffset
方法获取某数组元素的偏移地址,而后通过 CAS 实现原子性操作。
CAS 操作
介绍
这部分主要为 CAS 相关操作的方法。
1 | /** |
什么是 CAS? CAS 即比较并替换(Compare And Swap),是实现并发算法时常用到的一种技术。CAS 操作包含三个操作数——内存位置、预期原值及新值。执行 CAS 操作的时候,将内存位置的值与预期原值比较,如果相匹配,那么处理器会自动将该位置值更新为新值,否则,处理器不做任何操作。我们都知道,CAS 是一条 CPU 的原子指令(cmpxchg 指令),不会造成所谓的数据不一致问题,Unsafe
提供的 CAS 方法(如 compareAndSwapXXX
)底层实现即为 CPU 指令 cmpxchg
。
典型应用
在 JUC 包的并发工具类中大量地使用了 CAS 操作,像在前面介绍synchronized
和AQS
的文章中也多次提到了 CAS,其作为乐观锁在并发工具类中广泛发挥了作用。在 Unsafe
类中,提供了compareAndSwapObject
、compareAndSwapInt
、compareAndSwapLong
方法来实现的对Object
、int
、long
类型的 CAS 操作。以compareAndSwapInt
方法为例:
1 | public final native boolean compareAndSwapInt(Object o, long offset,int expected,int x); |
参数中o
为需要更新的对象,offset
是对象o
中整形字段的偏移量,如果这个字段的值与expected
相同,则将字段的值设为x
这个新值,并且此更新是不可被中断的,也就是一个原子操作。下面是一个使用compareAndSwapInt
的例子:
1 | private volatile int a; |
运行代码会依次输出:
1 | 1 2 3 4 5 6 7 8 9 |
在上面的例子中,使用两个线程去修改int
型属性a
的值,并且只有在a
的值等于传入的参数x
减一时,才会将a
的值变为x
,也就是实现对a
的加一的操作。流程如下所示:
需要注意的是,在调用compareAndSwapInt
方法后,会直接返回true
或false
的修改结果,因此需要我们在代码中手动添加自旋的逻辑。在AtomicInteger
类的设计中,也是采用了将compareAndSwapInt
的结果作为循环条件,直至修改成功才退出死循环的方式来实现的原子性的自增操作。
线程调度
介绍
Unsafe
类中提供了park
、unpark
、monitorEnter
、monitorExit
、tryMonitorEnter
方法进行线程调度。
1 | //取消阻塞线程 |
方法 park
、unpark
即可实现线程的挂起与恢复,将一个线程进行挂起是通过 park
方法实现的,调用 park
方法后,线程将一直阻塞直到超时或者中断等条件出现;unpark
可以终止一个挂起的线程,使其恢复正常。
此外,Unsafe
源码中monitor
相关的三个方法已经被标记为deprecated
,不建议被使用:
1 | //获得对象锁 |
monitorEnter
方法用于获得对象锁,monitorExit
用于释放对象锁,如果对一个没有被monitorEnter
加锁的对象执行此方法,会抛出IllegalMonitorStateException
异常。tryMonitorEnter
方法尝试获取对象锁,如果成功则返回true
,反之返回false
。
典型应用
Java 锁和同步器框架的核心类 AbstractQueuedSynchronizer
(AQS),就是通过调用LockSupport.park()
和LockSupport.unpark()
实现线程的阻塞和唤醒的,而 LockSupport
的 park
、unpark
方法实际是调用 Unsafe
的 park
、unpark
方式实现的。
1 | public static void park(Object blocker) { |
LockSupport
的park
方法调用了 Unsafe
的park
方法来阻塞当前线程,此方法将线程阻塞后就不会继续往后执行,直到有其他线程调用unpark
方法唤醒当前线程。下面的例子对 Unsafe
的这两个方法进行测试:
1 | public static void main(String[] args) { |
程序输出为:
1 | park main mainThread |
程序运行的流程也比较容易看懂,子线程开始运行后先进行睡眠,确保主线程能够调用park
方法阻塞自己,子线程在睡眠 5 秒后,调用unpark
方法唤醒主线程,使主线程能继续向下执行。整个流程如下图所示:
Class 操作
介绍
Unsafe
对Class
的相关操作主要包括类加载和静态变量的操作方法。
静态属性读取相关的方法
1 | //获取静态属性的偏移量 |
创建一个包含静态属性的类,进行测试:
1 |
|
运行结果:
1 | falseHydra |
在 Unsafe
的对象操作中,我们学习了通过objectFieldOffset
方法获取对象属性偏移量并基于它对变量的值进行存取,但是它不适用于类中的静态属性,这时候就需要使用staticFieldOffset
方法。在上面的代码中,只有在获取Field
对象的过程中依赖到了Class
,而获取静态变量的属性时不再依赖于Class
。
在上面的代码中首先创建一个User
对象,这是因为如果一个类没有被实例化,那么它的静态属性也不会被初始化,最后获取的字段属性将是null
。所以在获取静态属性前,需要调用shouldBeInitialized
方法,判断在获取前是否需要初始化这个类。如果删除创建 User 对象的语句,运行结果会变为:
1 | truenull |
使用defineClass方法允许程序在运行时动态地创建一个类
1 | public native Class<?> defineClass(String name, byte[] b, int off, int len, ClassLoader loader,ProtectionDomain protectionDomain); |
在实际使用过程中,可以只传入字节数组、起始字节的下标以及读取的字节长度,默认情况下,类加载器(ClassLoader
)和保护域(ProtectionDomain
)来源于调用此方法的实例。下面的例子中实现了反编译生成后的 class 文件的功能:
1 | private static void defineTest() { |
在上面的代码中,首先读取了一个class
文件并通过文件流将它转化为字节数组,之后使用defineClass
方法动态的创建了一个类,并在后续完成了它的实例化工作,流程如下图所示,并且通过这种方式创建的类,会跳过 JVM 的所有安全检查。
除了defineClass
方法外,Unsafe 还提供了一个defineAnonymousClass
方法:
1 | public native Class<?> defineAnonymousClass(Class<?> hostClass, byte[] data, Object[] cpPatches); |
使用该方法可以用来动态的创建一个匿名类,在Lambda
表达式中就是使用 ASM 动态生成字节码,然后利用该方法定义实现相应的函数式接口的匿名类。在 JDK 15 发布的新特性中,在隐藏类(Hidden classes
)一条中,指出将在未来的版本中弃用 Unsafe
的defineAnonymousClass
方法。
典型应用
Lambda 表达式实现需要依赖 Unsafe
的 defineAnonymousClass
方法定义实现相应的函数式接口的匿名类。
系统信息
介绍
这部分包含两个获取系统相关信息的方法。
1 | //返回系统指针的大小。返回值为4(32位系统)或 8(64位系统)。 |
典型应用
这两个方法的应用场景比较少,在java.nio.Bits
类中,在使用pageCount
计算所需的内存页的数量时,调用了pageSize
方法获取内存页的大小。另外,在使用copySwapMemory
方法拷贝内存时,调用了addressSize
方法,检测 32 位系统的情况。
总结
在本文中,我们首先介绍了 Unsafe
的基本概念、工作原理,并在此基础上,对它的 API 进行了说明与实践。相信大家通过这一过程,能够发现 Unsafe
在某些场景下,确实能够为我们提供编程中的便利。但是回到开头的话题,在使用这些便利时,确实存在着一些安全上的隐患,在我看来,一项技术具有不安全因素并不可怕,可怕的是它在使用过程中被滥用。尽管之前有传言说会在 Java9 中移除 Unsafe
类,不过它还是照样已经存活到了 Java16。按照存在即合理的逻辑,只要使用得当,它还是能给我们带来不少的帮助,因此最后还是建议大家,在使用 Unsafe
的过程中一定要做到使用谨慎使用、避免滥用。
Java SPI 机制详解
在面向对象的设计原则中,一般推荐模块之间基于接口编程,通常情况下调用方模块是不会感知到被调用方模块的内部具体实现。一旦代码里面涉及具体实现类,就违反了开闭原则。如果需要替换一种实现,就需要修改代码。
为了实现在模块装配的时候不用在程序里面动态指明,这就需要一种服务发现机制。Java SPI 就是提供了这样一个机制:为某个接口寻找服务实现的机制。这有点类似 IoC 的思想,将装配的控制权移交到了程序之外。
SPI 介绍
何谓 SPI?
SPI 即 Service Provider Interface ,字面意思就是:“服务提供者的接口”,我的理解是:专门提供给服务提供者或者扩展框架功能的开发者去使用的一个接口。
SPI 将服务接口和具体的服务实现分离开来,将服务调用方和服务实现者解耦,能够提升程序的扩展性、可维护性。修改或者替换服务实现并不需要修改调用方。
很多框架都使用了 Java 的 SPI 机制,比如:Spring 框架、数据库加载驱动、日志接口、以及 Dubbo 的扩展实现等等。
SPI 和 API 有什么区别?
那 SPI 和 API 有啥区别?
说到 SPI 就不得不说一下 API 了,从广义上来说它们都属于接口,而且很容易混淆。下面先用一张图说明一下:
一般模块之间都是通过通过接口进行通讯,那我们在服务调用方和服务实现方(也称服务提供者)之间引入一个“接口”。
当实现方提供了接口和实现,我们可以通过调用实现方的接口从而拥有实现方给我们提供的能力,这就是 API ,这种接口和实现都是放在实现方的。
当接口存在于调用方这边时,就是 SPI ,由接口调用方确定接口规则,然后由不同的厂商去根据这个规则对这个接口进行实现,从而提供服务。
举个通俗易懂的例子:公司 H 是一家科技公司,新设计了一款芯片,然后现在需要量产了,而市面上有好几家芯片制造业公司,这个时候,只要 H 公司指定好了这芯片生产的标准(定义好了接口标准),那么这些合作的芯片公司(服务提供者)就按照标准交付自家特色的芯片(提供不同方案的实现,但是给出来的结果是一样的)。
实战演示
Spring 框架提供的日志服务 SLF4J 其实只是一个日志门面(接口),但是 SLF4J 的具体实现可以有几种,比如:Logback、Log4j、Log4j2 等等,而且还可以切换,在切换日志具体实现的时候我们是不需要更改项目代码的,只需要在 Maven 依赖里面修改一些 pom 依赖就好了。
这就是依赖 SPI 机制实现的,那我们接下来就实现一个简易版本的日志框架。
Service Provider Interface
新建一个 Java 项目 service-provider-interface
目录结构如下:(注意直接新建 Java 项目就好了,不用新建 Maven 项目,Maven 项目会涉及到一些编译配置,如果有私服的话,直接 deploy 会比较方便,但是没有的话,在过程中可能会遇到一些奇怪的问题。)
1 | │ service-provider-interface.iml |
新建 Logger
接口,这个就是 SPI , 服务提供者接口,后面的服务提供者就要针对这个接口进行实现。
1 | package edu.jiangxuan.up.spi; |
接下来就是 LoggerService
类,这个主要是为服务使用者(调用方)提供特定功能的。这个类也是实现 Java SPI 机制的关键所在,如果存在疑惑的话可以先往后面继续看。
1 | package edu.jiangxuan.up.spi; |
新建 Main
类(服务使用者,调用方),启动程序查看结果。
1 | package org.spi.service; |
程序结果:
info 中没有发现 Logger 服务提供者 debug 中没有发现 Logger 服务提供者
此时我们只是空有接口,并没有为 Logger
接口提供任何的实现,所以输出结果中没有按照预期打印相应的结果。
你可以使用命令或者直接使用 IDEA 将整个程序直接打包成 jar 包。
Service Provider
接下来新建一个项目用来实现 Logger
接口
新建项目 service-provider
目录结构如下:
1 | │ service-provider.iml |
新建 Logback
类
1 | package edu.jiangxuan.up.spi.service; |
将 service-provider-interface
的 jar 导入项目中。
新建 lib 目录,然后将 jar 包拷贝过来,再添加到项目中。
接下来就可以在项目中导入 jar 包里面的一些类和方法了,就像 JDK 工具类导包一样的。
实现 Logger
接口,在 src
目录下新建 META-INF/services
文件夹,然后新建文件 edu.jiangxuan.up.spi.Logger
(SPI 的全类名),文件里面的内容是:edu.jiangxuan.up.spi.service.Logback
(Logback 的全类名,即 SPI 的实现类的包名 + 类名)。
这是 JDK SPI 机制 ServiceLoader 约定好的标准。
这里先大概解释一下:Java 中的 SPI 机制就是在每次类加载的时候会先去找到 class 相对目录下的 META-INF
文件夹下的 services 文件夹下的文件,将这个文件夹下面的所有文件先加载到内存中,然后根据这些文件的文件名和里面的文件内容找到相应接口的具体实现类,找到实现类后就可以通过反射去生成对应的对象,保存在一个 list 列表里面,所以可以通过迭代或者遍历的方式拿到对应的实例对象,生成不同的实现。
所以会提出一些规范要求:文件名一定要是接口的全类名,然后里面的内容一定要是实现类的全类名,实现类可以有过个,直接换行就好了,多个实现类的时候,会一个一个的迭代加载。
接下来同样将 service-provider
项目打包成 jar 包,这个 jar 包就是服务提供方的实现。通常我们导入 maven 的 pom 依赖就有点类似这种,只不过我们现在没有将这个 jar 包发布到 maven 公共仓库中,所以在需要使用的地方只能手动的添加到项目中。
效果展示
为了更直观的展示效果,我这里再新建一个专门用来测试的工程项目:java-spi-test
然后先导入 Logger
的接口 jar 包,再导入具体的实现类的 jar 包。
新建 Main 方法测试:
1 | package edu.jiangxuan.up.service; |
运行结果如下:
Logback info 打印日志:你好 Logback debug 打印日志:测试 Java SPI 机制
说明导入 jar 包中的实现类生效了。
如果我们不导入具体的实现类的 jar 包,那么此时程序运行的结果就会是:
info 中没有发现 Logger 服务提供者 debug 中没有发现 Logger 服务提供者
通过使用 SPI 机制,可以看出服务(LoggerService
)和 服务提供者两者之间的耦合度非常低,如果说我们想要换一种实现,那么其实只需要修改 service-provider
项目中针对 Logger
接口的具体实现就可以了,只需要换一个 jar 包即可,也可以有在一个项目里面有多个实现,这不就是 SLF4J 原理吗?
如果某一天需求变更了,此时需要将日志输出到消息队列,或者做一些别的操作,这个时候完全不需要更改 Logback 的实现,只需要新增一个服务实现(service-provider)可以通过在本项目里面新增实现也可以从外部引入新的服务实现 jar 包。我们可以在服务(LoggerService)中选择一个具体的 服务实现(service-provider) 来完成我们需要的操作。
那么接下来我们具体来说说 Java SPI 工作的重点原理—— ServiceLoader 。
ServiceLoader
ServiceLoader 具体实现
想要使用 Java 的 SPI 机制是需要依赖 ServiceLoader
来实现的,那么我们接下来看看 ServiceLoader
具体是怎么做的:
ServiceLoader
是 JDK 提供的一个工具类, 位于package java.util;
包下。
1 | A facility to load implementations of a service. |
这是 JDK 官方给的注释:一种加载服务实现的工具。
再往下看,我们发现这个类是一个 final
类型的,所以是不可被继承修改,同时它实现了 Iterable
接口。之所以实现了迭代器,是为了方便后续我们能够通过迭代的方式得到对应的服务实现。
1 | public final class ServiceLoader<S> implements Iterable<S>{ xxx...} |
可以看到一个熟悉的常量定义:
private static final String PREFIX = "META-INF/services/";
下面是 load
方法:可以发现 load
方法支持两种重载后的入参;
1 | public static <S> ServiceLoader<S> load(Class<S> service) { |
根据代码的调用顺序,在 reload()
方法中是通过一个内部类 LazyIterator
实现的。先继续往下面看。
ServiceLoader
实现了 Iterable
接口的方法后,具有了迭代的能力,在这个 iterator
方法被调用时,首先会在 ServiceLoader
的 Provider
缓存中进行查找,如果缓存中没有命中那么则在 LazyIterator
中进行查找。
1 | public Iterator<S> iterator() { |
在调用 LazyIterator
时,具体实现如下:
1 | public boolean hasNext() { |
可能很多人看这个会觉得有点复杂,没关系,我这边实现了一个简单的 ServiceLoader
的小模型,流程和原理都是保持一致的,可以先从自己实现一个简易版本的开始学:
自己实现一个 ServiceLoader
我先把代码贴出来:
1 | package edu.jiangxuan.up.service; |
关键信息基本已经通过代码注释描述出来了,
主要的流程就是:
- 通过 URL 工具类从 jar 包的
/META-INF/services
目录下面找到对应的文件, - 读取这个文件的名称找到对应的 spi 接口,
- 通过
InputStream
流将文件里面的具体实现类的全类名读取出来, - 根据获取到的全类名,先判断跟 spi 接口是否为同一类型,如果是的,那么就通过反射的机制构造对应的实例对象,
- 将构造出来的实例对象添加到
Providers
的列表中。
总结
其实不难发现,SPI 机制的具体实现本质上还是通过反射完成的。即:我们按照规定将要暴露对外使用的具体实现类在 META-INF/services/ 文件下声明。
另外,SPI 机制在很多框架中都有应用:Spring 框架的基本原理也是类似的反射。还有 Dubbo 框架提供同样的 SPI 扩展机制,只不过 Dubbo 和 spring 框架中的 SPI 机制具体实现方式跟咱们今天学得这个有些细微的区别,不过整体的原理都是一致的,相信大家通过对 JDK 中 SPI 机制的学习,能够一通百通,加深对其他高深框的理解。
通过 SPI 机制能够大大地提高接口设计的灵活性,但是 SPI 机制也存在一些缺点,比如:
- 遍历加载所有的实现类,这样效率还是相对较低的;
- 当多个
ServiceLoader
同时load
时,会有并发问题。
Java 语法糖详解
语法糖是大厂 Java 面试常问的一个知识点。
本文从 Java 编译原理角度,深入字节码及 class 文件,抽丝剥茧,了解 Java 中的语法糖原理及用法,帮助大家在学会如何使用 Java 语法糖的同时,了解这些语法糖背后的原理。
什么是语法糖?
语法糖(Syntactic Sugar) 也称糖衣语法,是英国计算机学家 Peter.J.Landin 发明的一个术语,指在计算机语言中添加的某种语法,这种语法对语言的功能并没有影响,但是更方便程序员使用。简而言之,语法糖让程序更加简洁,有更高的可读性。
有意思的是,在编程领域,除了语法糖,还有语法盐和语法糖精的说法,篇幅有限这里不做扩展了。
我们所熟知的编程语言中几乎都有语法糖。作者认为,语法糖的多少是评判一个语言够不够牛逼的标准之一。很多人说 Java 是一个“低糖语言”,其实从 Java 7 开始 Java 语言层面上一直在添加各种糖,主要是在“Project Coin”项目下研发。尽管现在 Java 有人还是认为现在的 Java 是低糖,未来还会持续向着“高糖”的方向发展。
Java 中有哪些常见的语法糖?
前面提到过,语法糖的存在主要是方便开发人员使用。但其实, Java 虚拟机并不支持这些语法糖。这些语法糖在编译阶段就会被还原成简单的基础语法结构,这个过程就是解语法糖。
说到编译,大家肯定都知道,Java 语言中,javac
命令可以将后缀名为.java
的源文件编译为后缀名为.class
的可以运行于 Java 虚拟机的字节码。如果你去看com.sun.tools.javac.main.JavaCompiler
的源码,你会发现在compile()
中有一个步骤就是调用desugar()
,这个方法就是负责解语法糖的实现的。
Java 中最常用的语法糖主要有泛型、变长参数、条件编译、自动拆装箱、内部类等。本文主要来分析下这些语法糖背后的原理。一步一步剥去糖衣,看看其本质。
我们这里会用到反编译open in new window,你可以通过 Decompilers onlineopen in new window 对 Class 文件进行在线反编译。
switch 支持 String 与枚举
前面提到过,从 Java 7 开始,Java 语言中的语法糖在逐渐丰富,其中一个比较重要的就是 Java 7 中switch
开始支持String
。
在开始之前先科普下,Java 中的switch
自身原本就支持基本类型。比如int
、char
等。对于int
类型,直接进行数值的比较。对于char
类型则是比较其 ascii 码。所以,对于编译器来说,switch
中其实只能使用整型,任何类型的比较都要转换成整型。比如byte
。short
,char
(ackii 码是整型)以及int
。
那么接下来看下switch
对String
得支持,有以下代码:
1 | public class switchDemoString { |
反编译后内容如下:
1 | public class switchDemoString |
看到这个代码,你知道原来 字符串的 switch 是通过equals()和hashCode()方法来实现的。 还好hashCode()
方法返回的是int
,而不是long
。
仔细看下可以发现,进行switch
的实际是哈希值,然后通过使用equals
方法比较进行安全检查,这个检查是必要的,因为哈希可能会发生碰撞。因此它的性能是不如使用枚举进行 switch
或者使用纯整数常量,但这也不是很差。
泛型
我们都知道,很多语言都是支持泛型的,但是很多人不知道的是,不同的编译器对于泛型的处理方式是不同的,通常情况下,一个编译器处理泛型有两种方式:Code specialization
和Code sharing
。C++和 C#是使用Code specialization
的处理机制,而 Java 使用的是Code sharing
的机制。
Code sharing 方式为每个泛型类型创建唯一的字节码表示,并且将该泛型类型的实例都映射到这个唯一的字节码表示上。将多种泛型类形实例映射到唯一的字节码表示是通过类型擦除(
type erasue
)实现的。
也就是说,对于 Java 虚拟机来说,他根本不认识Map<String, String> map这样的语法。需要在编译阶段通过类型擦除的方式进行解语法糖。
类型擦除的主要过程如下: 1.将所有的泛型参数用其最左边界(最顶级的父类型)类型替换。 2.移除所有的类型参数。
以下代码:
1 | Map<String, String> map = new HashMap<String, String>(); |
解语法糖之后会变成:
1 | Map map = new HashMap(); |
以下代码:
1 | public static <A extends Comparable<A>> A max(Collection<A> xs) { |
类型擦除后会变成:
1 | public static Comparable max(Collection xs){ |
虚拟机中没有泛型,只有普通类和普通方法,所有泛型类的类型参数在编译时都会被擦除,泛型类并没有自己独有的Class类对象。比如并不存在List
自动装箱与拆箱
自动装箱就是 Java 自动将原始类型值转换成对应的对象,比如将 int 的变量转换成 Integer 对象,这个过程叫做装箱,反之将 Integer 对象转换成 int 类型值,这个过程叫做拆箱。因为这里的装箱和拆箱是自动进行的非人为转换,所以就称作为自动装箱和拆箱。原始类型 byte, short, char, int, long, float, double 和 boolean 对应的封装类为 Byte, Short, Character, Integer, Long, Float, Double, Boolean。
先来看个自动装箱的代码:
1 | public static void main(String[] args) { |
反编译后代码如下:
1 | public static void main(String args[]) |
再来看个自动拆箱的代码:
1 | public static void main(String[] args) { |
反编译后代码如下:
1 | public static void main(String args[]) |
从反编译得到内容可以看出,在装箱的时候自动调用的是Integer
的valueOf(int)
方法。而在拆箱的时候自动调用的是Integer
的intValue
方法。
所以,装箱过程是通过调用包装器的 valueOf 方法实现的,而拆箱过程是通过调用包装器的 xxxValue 方法实现的。
可变长参数
可变参数(variable arguments
)是在 Java 1.5 中引入的一个特性。它允许一个方法把任意数量的值作为参数。
看下以下可变参数代码,其中 print
方法接收可变参数:
1 | public static void main(String[] args) |
反编译后代码:
1 | public static void main(String args[]) |
从反编译后代码可以看出,可变参数在被使用的时候,他首先会创建一个数组,数组的长度就是调用该方法是传递的实参的个数,然后再把参数值全部放到这个数组当中,然后再把这个数组作为参数传递到被调用的方法中。
枚举
Java SE5 提供了一种新的类型-Java 的枚举类型,关键字enum
可以将一组具名的值的有限集合创建为一种新的类型,而这些具名的值可以作为常规的程序组件使用,这是一种非常有用的功能。
要想看源码,首先得有一个类吧,那么枚举类型到底是什么类呢?是enum
吗?答案很明显不是,enum
就和class
一样,只是一个关键字,他并不是一个类,那么枚举是由什么类维护的呢,我们简单的写一个枚举:
1 | public enum t { |
然后我们使用反编译,看看这段代码到底是怎么实现的,反编译后代码内容如下:
1 | public final class T extends Enum |
通过反编译后代码我们可以看到,public final class T extends Enum
,说明,该类是继承了Enum
类的,同时final
关键字告诉我们,这个类也是不能被继承的。
当我们使用enum来定义一个枚举类型的时候,编译器会自动帮我们创建一个final类型的类继承Enum类,所以枚举类型不能被继承。
内部类
内部类又称为嵌套类,可以把内部类理解为外部类的一个普通成员。
内部类之所以也是语法糖,是因为它仅仅是一个编译时的概念,outer.java里面定义了一个内部类inner,一旦编译成功,就会生成两个完全不同的.class文件了,分别是outer.class和outer$inner.class。所以内部类的名字完全可以和它的外部类名字相同。
1 | public class OutterClass { |
以上代码编译后会生成两个 class 文件:OutterClass$InnerClass.class
、OutterClass.class
。当我们尝试对OutterClass.class
文件进行反编译的时候,命令行会打印以下内容:Parsing OutterClass.class...Parsing inner class OutterClass$InnerClass.class... Generating OutterClass.jad
。他会把两个文件全部进行反编译,然后一起生成一个OutterClass.jad
文件。文件内容如下:
1 | public class OutterClass |
条件编译
—般情况下,程序中的每一行代码都要参加编译。但有时候出于对程序代码优化的考虑,希望只对其中一部分内容进行编译,此时就需要在程序中加上条件,让编译器只对满足条件的代码进行编译,将不满足条件的代码舍弃,这就是条件编译。
如在 C 或 CPP 中,可以通过预处理语句来实现条件编译。其实在 Java 中也可实现条件编译。我们先来看一段代码:
1 | public class ConditionalCompilation { |
反编译后代码如下:
1 | public class ConditionalCompilation |
首先,我们发现,在反编译后的代码中没有System.out.println("Hello, ONLINE!");
,这其实就是条件编译。当if(ONLINE)
为 false 的时候,编译器就没有对其内的代码进行编译。
所以,Java 语法的条件编译,是通过判断条件为常量的 if 语句实现的。其原理也是 Java 语言的语法糖。根据 if 判断条件的真假,编译器直接把分支为 false 的代码块消除。通过该方式实现的条件编译,必须在方法体内实现,而无法在正整个 Java 类的结构或者类的属性上进行条件编译,这与 C/C++的条件编译相比,确实更有局限性。在 Java 语言设计之初并没有引入条件编译的功能,虽有局限,但是总比没有更强。
断言
在 Java 中,assert
关键字是从 JAVA SE 1.4 引入的,为了避免和老版本的 Java 代码中使用了assert
关键字导致错误,Java 在执行的时候默认是不启动断言检查的(这个时候,所有的断言语句都将忽略!),如果要开启断言检查,则需要用开关-enableassertions
或-ea
来开启。
看一段包含断言的代码:
1 | public class AssertTest { |
反编译后代码如下:
1 | public class AssertTest { |
很明显,反编译之后的代码要比我们自己的代码复杂的多。所以,使用了 assert 这个语法糖我们节省了很多代码。其实断言的底层实现就是 if 语言,如果断言结果为 true,则什么都不做,程序继续执行,如果断言结果为 false,则程序抛出 AssertError 来打断程序的执行。-enableassertions
会设置$assertionsDisabled 字段的值。
数值字面量
在 java 7 中,数值字面量,不管是整数还是浮点数,都允许在数字之间插入任意多个下划线。这些下划线不会对字面量的数值产生影响,目的就是方便阅读。
比如:
1 | public class Test { |
反编译后:
1 | public class Test |
反编译后就是把_
删除了。也就是说 编译器并不认识在数字字面量中的_,需要在编译阶段把他去掉。
for-each
增强 for 循环(for-each
)相信大家都不陌生,日常开发经常会用到的,他会比 for 循环要少写很多代码,那么这个语法糖背后是如何实现的呢?
1 | public static void main(String... args) { |
反编译后代码如下:
1 | public static transient void main(String args[]) |
代码很简单,for-each 的实现原理其实就是使用了普通的 for 循环和迭代器。
try-with-resource
Java 里,对于文件操作 IO 流、数据库连接等开销非常昂贵的资源,用完之后必须及时通过 close 方法将其关闭,否则资源会一直处于打开状态,可能会导致内存泄露等问题。
关闭资源的常用方式就是在finally
块里是释放,即调用close
方法。比如,我们经常会写这样的代码:
1 | public static void main(String[] args) { |
从 Java 7 开始,jdk 提供了一种更好的方式关闭资源,使用try-with-resources
语句,改写一下上面的代码,效果如下:
1 | public static void main(String... args) { |
看,这简直是一大福音啊,虽然我之前一般使用IOUtils
去关闭流,并不会使用在finally
中写很多代码的方式,但是这种新的语法糖看上去好像优雅很多呢。看下他的背后:
1 | public static transient void main(String args[]) |
其实背后的原理也很简单,那些我们没有做的关闭资源的操作,编译器都帮我们做了。所以,再次印证了,语法糖的作用就是方便程序员的使用,但最终还是要转成编译器认识的语言。
Lambda 表达式
关于 lambda 表达式,有人可能会有质疑,因为网上有人说他并不是语法糖。其实我想纠正下这个说法。Labmda 表达式不是匿名内部类的语法糖,但是他也是一个语法糖。实现方式其实是依赖了几个 JVM 底层提供的 lambda 相关 api。
先来看一个简单的 lambda 表达式。遍历一个 list:
1 | public static void main(String... args) { |
为啥说他并不是内部类的语法糖呢,前面讲内部类我们说过,内部类在编译之后会有两个 class 文件,但是,包含 lambda 表达式的类编译后只有一个文件。
反编译后代码如下:
1 | public static /* varargs */ void main(String ... args) { |
可以看到,在forEach
方法中,其实是调用了java.lang.invoke.LambdaMetafactory#metafactory
方法,该方法的第四个参数 implMethod
指定了方法实现。可以看到这里其实是调用了一个lambda$main$0
方法进行了输出。
再来看一个稍微复杂一点的,先对 List 进行过滤,然后再输出:
1 | public static void main(String... args) { |
反编译后代码如下:
1 | public static /* varargs */ void main(String ... args) { |
两个 lambda 表达式分别调用了lambda$main$1
和lambda$main$0
两个方法。
所以,lambda 表达式的实现其实是依赖了一些底层的 api,在编译阶段,编译器会把 lambda 表达式进行解糖,转换成调用内部 api 的方式。
可能遇到的坑
泛型
一、当泛型遇到重载
1 | public class GenericTypes { |
上面这段代码,有两个重载的函数,因为他们的参数类型不同,一个是List<String>
另一个是List<Integer>
,但是,这段代码是编译通不过的。因为我们前面讲过,参数List<Integer>
和List<String>
编译之后都被擦除了,变成了一样的原生类型 List,擦除动作导致这两个方法的特征签名变得一模一样。
二、当泛型遇到 catch
泛型的类型参数不能用在 Java 异常处理的 catch 语句中。因为异常处理是由 JVM 在运行时刻来进行的。由于类型信息被擦除,JVM 是无法区分两个异常类型MyException<String>
和MyException<Integer>
的
三、当泛型内包含静态变量
1 | public class StaticTest{ |
以上代码输出结果为:2!
由于经过类型擦除,所有的泛型类实例都关联到同一份字节码上,泛型类的所有静态变量是共享的。
自动装箱与拆箱
对象相等比较
1 | public static void main(String[] args) { |
输出结果:
1 | a == b is false |
在 Java 5 中,在 Integer 的操作上引入了一个新功能来节省内存和提高性能。整型对象通过使用相同的对象引用实现了缓存和重用。
适用于整数值区间-128 至 +127。
只适用于自动装箱。使用构造函数创建对象不适用。
增强 for 循环
1 | for (Student stu : students) { |
会抛出ConcurrentModificationException
异常。
Iterator 是工作在一个独立的线程中,并且拥有一个 mutex 锁。 Iterator 被创建之后会建立一个指向原来对象的单链索引表,当原来的对象数量发生变化时,这个索引表的内容不会同步改变,所以当索引指针往后移动的时候就找不到要迭代的对象,所以按照 fail-fast 原则 Iterator 会马上抛出java.util.ConcurrentModificationException
异常。
所以 Iterator
在工作的时候是不允许被迭代的对象被改变的。但你可以使用 Iterator
本身的方法remove()
来删除对象,Iterator.remove()
方法会在删除当前迭代对象的同时维护索引的一致性。
总结
前面介绍了 12 种 Java 中常用的语法糖。所谓语法糖就是提供给开发人员便于开发的一种语法而已。但是这种语法只有开发人员认识。要想被执行,需要进行解糖,即转成 JVM 认识的语法。当我们把语法糖解糖之后,你就会发现其实我们日常使用的这些方便的语法,其实都是一些其他更简单的语法构成的。
有了这些语法糖,我们在日常开发的时候可以大大提升效率,但是同时也要避免过渡使用。使用之前最好了解下原理,避免掉坑。