第13章_枚举

gong_yz大约 17 分钟JAVAJAVASE

1、枚举的用法

枚举类型（enumtype）是指由一组固定的常量组成合法的类型。Java中由关键字enum来定义一个枚举类型。

比如定义一个季节的枚举：

public enum Season{
    SPRING,SUMMER,AUTUMN,WINNER;
}

有了以上的枚举，在程序中引用春天时，就可以直接使用SPRING这个枚举项了。

在java语言中还没有引入枚举类型之前，表示枚举类型的常用模式是声明一组具有int常量。之前我们通常利用public final static 方法定义的代码如下，分别用1 表示春天，2表示夏天，3表示秋天，4表示冬天。

public class Season {
    public static final int SPRING = 1;
    public static final int SUMMER = 2;
    public static final int AUTUMN = 3;
    public static final int WINTER = 4;
}

这种方式和枚举相比，安全性、易用性和可读性都比较差。

Java枚举有以下特点：

  • 使用关键字enum创建枚举
  • 一个枚举中包含若干枚举项，如Season包含SPRING,SUMMER,AUTUMN,WINNER;
  • 枚举可以实现一个或多个接口
  • 枚举可以配合switch使用

在以下四个例子中，我们运用了上面介绍的前4个特点：

/**
 *  运算接口
 *  @return
 */
public interface Operation {
	double operate(double x, double y);
}
public enum BasicOperation implements Operation {
	PLUS("+", "加法") {
		@Override
		        public double operate(double x, double y) {
			return x + y;
		}
	}
	,
	MINUS("-", "减法") {
		@Override
		    public double operate(double x, double y) {
			return x - y;
		}
	}
	,
	MULTIPLY("*", "乘法") {
		@Override
		    public double operate(double x, double y) {
			return x * y;
		}
	}
	,
	DIVIDE("/", "除法") {
		@Override
		    public double operate(double x, double y) {
			return x / y;
		}
	}
	,
	;
	public String symbol;
	private String name;
	BasicOperation(String symbol, String name) {
		this.symbol = symbol;
		this.name = name;
	}
}

2、枚举是如何实现的

相关信息

实现原理

想要了解枚举的实现原理，最简单的办法就是查看JAVA中的源代码，那么枚举类型到底是什么类呢？是enum吗？答案很明显不是，enum就和class一样，只是一个关键字，他并不是一个类，那么枚举是由什么类维护的呢，我们简单的写一个枚举：

public enum t {
    SPRING,SUMMER;
}

然后我们使用反编译，看看这段代码到底是怎么实现的，反编译后代码内容如下：

public final class T extends Enum
{
	private T(String s, int i)
	    {
		super(s, i);
	}
	public static T[] values()
	    {
		T at[];
		int i;
		T at1[];
		System.arraycopy(at = ENUM$VALUES, 0, at1 = new T[i = at.length], 0, i);
		return at1;
	}
	public static T valueOf(String s)
	{
		return (T)Enum.valueOf(demo/T, s);
	}
	public static final T SPRING;
	public static final T SUMMER;
	private static final T ENUM$VALUES[];
	static
	{
		SPRING = new T("SPRING", 0);
		SUMMER = new T("SUMMER", 1);
		ENUM$VALUES = (new T[] {
		        SPRING, SUMMER
		    });
	}
}

通过反编译代码我们可以看到，public final class T extends Enum，说明，该类是继承了Enum类的。

java.lang.Enum类是一个抽象类，定义如下：

public abstract class Enum<E extends Enum<E>>  implements Constable, Comparable<E>, Serializable{
    private final String name;
    private final int ordinal;
}

可以看到，Enum中定义了两个成员变量，分别是name，ordinal。因为有name的存在，所以我们必须给枚举的枚举项定义一个名字；因为有ordinal的存在，所以枚举项默认有一个整数类型的序号。

当我们使用enum定义枚举类型时，编译器会自动帮助我们创建一个类继承自Enum类。因为定义出来的是final类型的，所以枚举类是不能被继承的。

当我们使用enmu来定义一个枚举类型的时候，编译器会自动帮我们创建一个final类型的类继承Enum类，所以枚举类型不能被继承。

3、如何比较Java中的枚举

java枚举值比较用==和equals方法没啥区别，两个随便用都是一样的效果。因为枚举Enum类的equals方法默认实现就是通过 == 来比较的；

类似的Enum的compareTo方法比较的是Enum的ordinal顺序大小；所以，先定义的枚举项要小于后定义的枚举项。

4、switch对枚举的支持

实质上还是将枚举转换成int类型来提供的。

Java 1.7 之前 switch 参数可用类型为 short、byte、int、char，枚举类型之所以能使用其实是编译器层面实现的

编译器会将枚举 switch 转换为类似

switch(s.ordinal()) { 
    case Status.START.ordinal() 
}

形式，所以实质还是 int 参数类型，感兴趣的可以自己写个使用枚举的 switch 代码然后通过 javap -v 去看下字节码就明白了。

5、如何实现枚举的序列化

枚举的序列化机制

Enum constants are serialized differently than ordinary serializable or externalizable objects. The serialized form of an enum constant consists solely of its name; field values of the constant are not present in the form. To serialize an enum constant, ObjectOutputStream writes the value returned by the enum constant's name method. To deserialize an enum constant, ObjectInputStream reads the constant name from the stream; the deserialized constant is then obtained by calling the java.lang.Enum.valueOf method, passing the constant's enum type along with the received constant name as arguments. Like other serializable or externalizable objects, enum constants can function as the targets of back references appearing subsequently in the serialization stream. The process by which enum constants are serialized cannot be customized: any class-specific writeObject, readObject, readObjectNoData, writeReplace, and readResolve methods defined by enum types are ignored during serialization and deserialization. Similarly, any serialPersistentFields or serialVersionUID field declarations are also ignored--all enum types have a fixedserialVersionUID of 0L. Documenting serializable fields and data for enum types is unnecessary, since there is no variation in the type of data sent.

大概意思就是说，在序列化的时候Java仅仅是将枚举对象的name属性输出到结果中，反序列化的时候则是通过java.lang.Enum的valueOf方法来根据名字查找枚举对象。

同时，编译器是不允许任何对这种序列化机制的定制的，因此禁用了writeObject、readObject、readObjectNoData、writeReplace和readResolve等方法。 我们看一下这个valueOf方法：

public static <T extends Enum<T>> T valueOf(Class<T> enumType,String name) {
	T result = enumType.enumConstantDirectory().get(name);
	if (result != null)  
	                return result;
	if (name == null)  
	                throw new NullPointerException("Name is null");
	throw new IllegalArgumentException(  
	                "No enum const " + enumType +"." + name);
}

从代码中可以看到，代码会尝试从调用enumType这个Class对象的enumConstantDirectory()方法返回的map中获取名字为name的枚举对象，如果不存在就会抛出异常。再进一步跟到enumConstantDirectory()方法，就会发现到最后会以反射的方式调用enumType这个类型的values()静态方法，也就是上面我们看到的编译器为我们创建的那个方法，然后用返回结果填充enumType这个Class对象中的enumConstantDirectory属性。

为什么要针对枚举的序列化做出特殊的约定呢？

  • 这其实和枚举的特性有关，根据Java规范的规定，每一个枚举类型及其定义的枚举变量在JVM中都是唯一的。也就是说，每一个枚举项在JVM中都是单例的。
  • 在前面提到过，序列化+反序列化是可以破坏单例模式的，所以java就针对枚举的序列化做出如前面介绍的特殊规定。

6、为什么说枚举是实现单例最好的方式

6.1 哪种写单例的方式最好

在StackOverflow中，有一个关于What is an efficient way to implement a singleton pattern in Java?的讨论，如图所示：

image-20230308175500241
image-20230308175500241

如上图，得票率最高的回答是：使用枚举。

回答者引用了Joshua Bloch大神在《Effective Java》中明确表达过的观点：

  • 使用枚举实现单例的方法虽然还没有广泛采用，但是单元素的枚举类型已经成为实现Singleton的最佳方法。

如果你真的深入理解了单例的用法以及一些可能存在的坑的话，那么你也许也能得到相同的结论，那就是：使用枚举实现单例是一种很好的方法。

6.2 枚举单例写法简单

如果你看过《单例模式的七种写法》中的实现单例的所有方式的代码，那就会发现，各种方式实现单例的代码都比较复杂。主要原因是在考虑线程安全问题。

我们简单对比下“双重校验锁”方式和枚举方式实现单例的代码。

“双重校验锁”实现单例：

public class Singleton {  
    private volatile static Singleton singleton;  
    private Singleton (){}  
    public static Singleton getSingleton() {  
        if (singleton == null) {  
            synchronized (Singleton.class) {  
                if (singleton == null) {  
                    singleton = new Singleton();  
                }  
            }  
        }  
        return singleton;  
    }  
}

枚举实现单例：

public enum Singleton {  
    INSTANCE;  
    public void whateverMethod() {  
    }  
}

相比之下，你就会发现，枚举实现单例的代码会精简很多。

上面的双重锁校验的代码之所以很臃肿，是因为大部分代码都是在保证线程安全。为了在保证线程安全和锁粒度之间做权衡，代码难免会写的复杂些。但是，这段代码还是有问题的，因为他无法解决反序列化会破坏单例的问题。

6.3 枚举可解决线程安全问题

为什么使用枚举就不需要解决线程安全问题呢？

  • 其实，并不是使用枚举就不需要保证线程安全，只不过线程安全的保证不需要我们关心而已。也就是说，其实在“底层”还是做了线程安全方面的保证的。
  • 这就要说到关于枚举的实现了。定义枚举时使用enum和class一样，是Java中的一个关键字。就像class对应用一个Class类一样，enum也对应有一个Enum类。
  • 通过将定义好的枚举反编译，我们就能发现，其实枚举在经过javac的编译之后，会被转换成形如public final class T extends Enum的定义。

而且，枚举中的各个枚举项同时通过static来定义的。如：

public enum T {
    SPRING,SUMMER,AUTUMN,WINTER;
}

反编译后代码为：

public final class T extends Enum
{
    //省略部分内容
    public static final T SPRING;
    public static final T SUMMER;
    public static final T AUTUMN;
    public static final T WINTER;
    private static final T ENUM$VALUES[];
    static
    {
        SPRING = new T("SPRING", 0);
        SUMMER = new T("SUMMER", 1);
        AUTUMN = new T("AUTUMN", 2);
        WINTER = new T("WINTER", 3);
        ENUM$VALUES = (new T[] {
            SPRING, SUMMER, AUTUMN, WINTER
        });
    }
}

static类型的属性会在类被加载之后被初始化，当一个Java类第一次被真正使用到的时候静态资源被初始化、Java类的加载和初始化过程都是线程安全的（因为虚拟机在加载枚举的类的时候，会使用ClassLoader的loadClass方法，而这个方法使用同步代码块保证了线程安全）。所以，创建一个enum类型是线程安全的。

也就是说，我们定义的一个枚举，在第一次被真正用到的时候，会被虚拟机加载并初始化，而这个初始化过程是线程安全的。而我们知道，解决单例的并发问题，主要解决的就是初始化过程中的线程安全问题。

所以，由于枚举的以上特性，枚举实现的单例是天生线程安全的。

6.4 枚举可解决反序列化会破坏单例的问题

普通的Java类的反序列化过程中，会通过反射调用类的默认构造函数来初始化对象。所以，即使单例中构造函数是私有的，也会被反射给破坏掉。由于反序列化后的对象是重新new出来的，所以这就破坏了单例。

但是，枚举的反序列化并不是通过反射实现的。所以，也就不会发生由于反序列化导致的单例破坏问题。

6.5 小结

在所有的单例实现方式中，枚举是一种在代码写法上最简单的方式，之所以代码十分简洁，是因为Java给我们提供了enum关键字，我们便可以很方便的声明一个枚举类型，而不需要关心其初始化过程中的线程安全问题，因为枚举类在被虚拟机加载的时候会保证线程安全的被初始化。

除此之外，在序列化方面，Java中有明确规定，枚举的序列化和反序列化是有特殊定制的。这就可以避免反序列化过程中由于反射而导致的单例被破坏问题。

7、为什么接口返回值不能使用枚举类型

7.1 背景

最近，我们的线上环境出现了一个问题，线上代码在执行过程中抛出了一个IllegalArgumentException，分析堆栈后，发现最根本的的异常是以下内容：

java.lang.IllegalArgumentException: 
No enum constant com.a.b.f.m.a.c.AType.P_M

大概就是以上的内容，看起来还是很简单的，提示的错误信息就是在AType这个枚举类中没有找到P_M这个枚举项。

于是经过排查，我们发现，在线上开始有这个异常之前，该应用依赖的一个下游系统有发布，而发布过程中是一个API包发生了变化，主要变化内容是在一个RPC接口的Response返回值类中的一个枚举参数AType中增加了P_M这个枚举项。

但是下游系统发布时，并未通知到我们负责的这个系统进行升级，所以就报错了。

我们来分析下为什么会发生这样的情况。

7.2 问题重现

首先，下游系统A提供了一个二方库的某一个接口的返回值中有一个参数类型是枚举类型。

一方库指的是本项目中的依赖 二方库指的是公司内部其他项目提供的依赖 三方库指的是其他组织、公司等来自第三方的依赖

public interface AFacadeService {
	public AResponse doSth(ARequest aRequest);
}
public Class AResponse{
	private Boolean success;
	private AType aType;
}
public enum AType{
	P_T,
	A_B
}

然后B系统依赖了这个二方库，并且会通过RPC远程调用的方式调用AFacadeService的doSth方法。

public class BService {
	@Autowired
	AFacadeService aFacadeService;
	public void doSth(){
		ARequest aRequest = new ARequest();
		AResponse aResponse = aFacadeService.doSth(aRequest);
		AType aType = aResponse.getAType();
	}
}

这时候，如果A和B系统依赖的都是同一个二方库的话，两者使用到的枚举AType会是同一个类，里面的枚举项也都是一致的，这种情况不会有什么问题。

但是，如果有一天，这个二方库做了升级，在AType这个枚举类中增加了一个新的枚举项P_M，这时候只有系统A做了升级，但是系统B并没有做升级。

那么A系统依赖的的AType就是这样的：

public enum AType{
	P_T,
	A_B,
	P_M
}

而B系统依赖的AType则是这样的：

public enum AType{
	P_T,
	A_B
}

这种情况下，在B系统通过RPC调用A系统的时候，如果A系统返回的AResponse中的aType的类型位新增的P_M时候，B系统就会无法解析。一般在这种时候，RPC框架就会发生反序列化异常。导致程序被中断。

7.3 原理分析

这个问题的现象我们分析清楚了，那么再来看下原理是怎样的，为什么出现这样的异常呢。

其实这个原理也不难，这类RPC框架大多数会采用JSON的格式进行数据传输，也就是客户端会将返回值序列化成JSON字符串，而服务端会再将JSON字符串反序列化成一个Java对象。

而JSON在反序列化的过程中，对于一个枚举类型，会尝试调用对应的枚举类的valueOf方法来获取到对应的枚举。

而我们查看枚举类的valueOf方法的实现时，就可以发现，如果从枚举类中找不到对应的枚举项的时候，就会抛出IllegalArgumentException：

public static <T extends Enum<T>> T valueOf(Class<T> enumType,
                                            String name) {
    T result = enumType.enumConstantDirectory().get(name);
    if (result != null)
        return result;
    if (name == null)
        throw new NullPointerException("Name is null");
    throw new IllegalArgumentException(
        "No enum constant " + enumType.getCanonicalName() + "." + name);
}

关于这个问题，其实在《阿里巴巴Java开发手册》中也有类似的约定：

image-20230308180014117
image-20230308180014117

这里面规定"对于二方库的参数可以使用枚举，但是返回值不允许使用枚举"。

7.4 扩展思考

为什么参数中可以有枚举？

一般情况下，A系统想要提供一个远程接口给别人调用的时候，就会定义一个二方库，告诉其调用方如何构造参数，调用哪个接口。

而这个二方库的调用方会根据其中定义的内容来进行调用。而参数的构造过程是由B系统完成的，如果B系统使用到的是一个旧的二方库，使用到的枚举自然是已有的一些，新增的就不会被用到，所以这样也不会出现问题。

比如前面的例子，B系统在调用A系统的时候，构造参数的时候使用到AType的时候就只有P_T和A_B两个选项，虽然A系统已经支持P_M了，但是B系统并没有使用到。

如果B系统想要使用P_M，那么就需要对该二方库进行升级。

但是，返回值就不一样了，返回值并不受客户端控制，服务端返回什么内容是根据他自己依赖的二方库决定的。

但是，其实相比较于手册中的规定，我更加倾向于，在RPC的接口中入参和出参都不要使用枚举。

一般，我们要使用枚举都是有几个考虑：

  • 枚举严格控制下游系统的传入内容，避免非法字符。
  • 方便下游系统知道都可以传哪些值，不容易出错。

不可否认，使用枚举确实有一些好处，但是我不建议使用主要有以下原因：

  • 如果二方库升级，并且删除了一个枚举中的部分枚举项，那么入参中使用枚举也会出现问题，调用方将无法识别该枚举项。
  • 有的时候，上下游系统有多个，如C系统通过B系统间接调用A系统，A系统的参数是由C系统传过来的，B系统只是做了一个参数的转换与组装。这种情况下，一旦A系统的二方库升级，那么B和C都要同时升级，任何一个不升级都将无法兼容。

我其实建议大家在接口中使用字符串代替枚举，相比较于枚举这种强类型，字符串算是一种弱类型。

如果使用字符串代替RPC接口中的枚举，那么就可以避免上面我们提到的两个问题，上游系统只需要传递字符串就行了，而具体的值的合法性，只需要在A系统内自己进行校验就可以了。

为了方便调用者使用，可以使用javadoc的@see注解表明这个字符串字段的取值从那个枚举中获取。

public Class AResponse{
	private Boolean success;
	/**
	 *  @see AType 
      */
	private String aType;
}

一些规模庞大的系统提供的一个接口，可能有上百个调用方，而接口升级也是常态，我们根本做不到每次二方库升级之后要求所有调用者跟着一起升级，这是完全不现实的，并且对于有些调用者来说，他用不到新特性，完全没必要做升级。

还有一种看起来比较特殊，但是实际上比较常见的情况，就是有的时候一个接口的声明在A包中，而一些枚举常量定义在B包中，比较常见的就是阿里的交易相关的信息，订单分很多层次，每次引入一个包的同时都需要引入几十个包。

对于调用者来说，我肯定是不希望我的系统引入太多的依赖的，一方面依赖多了会导致应用的编译过程很慢，并且很容易出现依赖冲突问题。

所以，在调用下游接口的时候，如果参数中字段的类型是枚举的话，那我没办法，必须得依赖他的二方库。但是如果不是枚举，只是一个字符串，那我就可以选择不依赖。

所以，我们在定义接口的时候，会尽量避免使用枚举这种强类型。

最后，我只是不建议在对外提供的接口的出入参中使用枚举，并不是说彻底不要用枚举。

默认页脚
Copyright © 2024 gong_yz