泛型（6）：擦除的神秘之处（下）

快来打我* 2023-07-16 06:57 9阅读 0赞

### 三、擦除的问题 ###

因此，擦除主要的正当理由是从非泛化代码到泛化代码的转变过程，以及在不破坏现有类库的情况下，将泛型融入java语言。擦除使得现有的非泛型客户端代码能够在不改变的情况下继续使用，直至客户端准备好用泛型重写这些代码。这是一个崇高的动机，因为它不会突然间破坏所有现有的代码。

擦除的代价是显著的。泛型不能用于显式地引用运行时类型的操作之中，例如转型、instanceof操作和new操作表达式。因为所有关于参数的类型信息都丢失了，无论何时，当你在编写泛型代码时，必须时刻提醒自己，你只是看起来好像拥有有关参数的类型信息而已。因此，如果你编写了下面这样的代码段：

class Foo<T> {
        T var;
    }

那么，看起来当你创建Foo的实例时：

Foo<Cat> f = new Foo<Cat>();

class Foo中的代码应该知道现在工作于Cat之上，而泛型语法也在强烈暗示：在整个类中的各个地方，类型T都在被替换。但事实并非如此，无论何时，当你在编写这个类的代码时，必须提醒自己：“不，它只是一个Object。”

另外，擦除和迁移兼容性意味着，使用泛型并不是强制的，尽管你可能希望这样：

class GenericBase<T> {
    	private T element;
    
    	public void set(T arg) {
    		element = arg;
    	}
    
    	public T get() {
    		return element;
    	}
    }
    
    class Derived1<T> extends GenericBase<T> {
    }
    
    class Derived2 extends GenericBase {
    }
    
    //class Derived3 extends GenericBase<?> {}
    
    public class ErasureAndInheritance {
    	@SuppressWarnings("unchecked")
    	public static void main(String[] args) {
    		Derived2 d2 = new Derived2();
    		Object object = d2.get();
    		d2.set(object);
    	}
    }

Derived2继承自GenericBase，但是没有任何泛型参数，而编译器不会发出任何警告。警告在set()被调用时才会出现。

为了关闭警告，java提供了一个注解，我们可以在列表中看到它（这个注解在java SE5之前的版本中不支持）：

@SuppressWarnings("unchecked")

注意，这个注解被放置在可以产生这类警告的方法之上，而不是整个类上。当你要关闭警告时，最好是尽量地“聚焦”，这样就不会因为过于宽泛地关闭警告，而导致意外地遮蔽掉真正的问题。

可以推断，Derived3产生的错误意味着编译器期望得到一个原生基类。

当你希望将类型参数不要仅仅当做Object处理时，就需要付出额外努力来管理边界，并且与在C++、Ada和Eiffel这样的语言中获得参数化类型相比，你需要付出多得多的努力来获得少得多的回报。这并不是说，对于大多数的编程问题而言，这些语言通常都会比java得心应手；这只是说，它们的参数化类型机制比java的更灵活、更强大。

### 四、边界处的动作 ###

正是因为有了擦除，我发现泛型最令人困惑的方面源自这样一个事实，即可以表示没有任何意义的事物。例如：

import java.lang.reflect.Array;
    import java.util.Arrays;
    
    public class ArrayMaker<T> {
    	private Class<T> kind;
    
    	public ArrayMaker(Class<T> kind) {
    		this.kind = kind;
    	}
    
    	@SuppressWarnings("unchecked")
    	T[] create(int size) {
    		return (T[]) Array.newInstance(kind, size);
    	}
    
    	public static void main(String[] args) {
    		ArrayMaker<String> stringMaker = new ArrayMaker<>(String.class);
    		String[] stringArray = stringMaker.create(9);
    		System.out.println(Arrays.toString(stringArray));
    	}
    }

即使kind被存储为Class<T>，擦除也意味着它实际将被存储为Class，没有任何参数。因此，当你在使用它时，例如在创建数组时，Array.newInstance()实际上并未拥有kind所蕴含的类型信息，因此这不会产生具体的结果，所以必须转型，这将产生一条令你无法满意的警告。

注意，对于在泛型中创建数组，使用Array.newInstance()是推荐的方式。如果我们要创建一个容器而不是数组，情况就有些不同了：

import java.util.ArrayList;
    import java.util.List;
    
    public class ListMaker<T> {
    	List<T> create() {
    		return new ArrayList<T>();
    	}
    
    	public static void main(String[] args) {
    		ListMaker<String> stringMaker = new ListMaker<>();
    		List<String> create = stringMaker.create();
    	}
    }

编译器不会给出任何警告，尽管我们（从擦除中）知道create()内部的new ArrayList<T>中的<T>被移除了——在运行时，这个类的内部没有任何<T>，因此这看起来毫无意义。但是如果你遵从这种思路，并将这个表达式改为new ArrayList()，编译器就会给出警告。

在本例中，这是否真的毫无意义呢？如果返回list之前，将某些对象放入其中，就像下面这样，情况又会如何呢？

import java.util.ArrayList;
    import java.util.List;
    
    public class FilledListMaker<T> {
    	List<T> create(T t, int n) {
    		List<T> result = new ArrayList<>();
    		for (int i = 0; i < n; i++) {
    			result.add(t);
    		}
    		return result;
    	}
    
    	public static void main(String[] args) {
    		FilledListMaker<String> stringMaker = new FilledListMaker<>();
    		List<String> list = stringMaker.create("Hello", 4);
    		System.out.println(list);
    	}
    }

即使编译器无法知道有关create()中的T的任何信息，但是它仍旧可以在编译期确保你放置到result中的对象具有T类型，使其适合ArrayList<T>。因此，即使擦除在方法或类内部移除了有关实际类型的信息，编译器仍旧可以确保在方法或类中使用的类型的内部一致性。

因为擦除在方法体中移除了类型信息，所以在运行时的问题就是边界：即对象进入和离开方法的地点。这些正是编译器在编译期执行类型检查并插入转型代码的地点。请考虑下面的非泛型示例：

public class SimpleHolder {
    	private Object obj;
    
    	public void set(Object obj) {
    		this.obj = obj;
    	}
    
    	public Object get() {
    		return obj;
    	}
    
    	public static void main(String[] args) {
    		SimpleHolder holder = new SimpleHolder();
    		holder.set("Item");
    		String s = (String) holder.get();
    	}
    }

如果用javap  -c SimpleHolder反编译这个类，就可以得到下面的（经过编辑的）内容：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70][]

set()和get()方法将直接存储和产生值，而转型是在调用get()的时候接受检查的。现在将泛型合并到上面的代码中：

public class GenericHolder<T> {
    	private T obj;
    
    	public void set(T obj) {
    		this.obj = obj;
    	}
    
    	public T get() {
    		return obj;
    	}
    
    	public static void main(String[] args) {
    		GenericHolder<String> holder = new GenericHolder<>();
    		holder.set("Item");
    		String s = holder.get();
    	}
    }

从get()返回之后的转型消失了，但是我们还知道传递给set()的值再编译期会接受检查。下面是相关的字节码：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70 1][]

所产生的字节码是相同的。对进入set()的类型进行检查是不需要的，因为这将由编译器执行。而对从get()返回的值进行转型仍旧是需要的，但这与你自己必须执行的操作是一样的——此处它将由编译器自动插入，因此你写入（和读取）的代码噪声将更小。

由于所产生的get()和set()的字节码相同，所以在泛型中的所有动作都发生在边界处——对传递进来的值进行额外的编译期检查，并插入对传递出去的值的转型。这有助于澄清对擦除的混淆，记住，“边界就是发生动作的地方”。

**如果本文对您有很大的帮助，还请点赞关注一下。**

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70]: /images/20230528/1c0309a554154002826d190730d895ea.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70 1]: /images/20230528/ca96b8baf6ae4042bd2c6857096695a6.png