如第25條所述，參數化類型是 不可變的（invariant）。換句話說，對于任何兩個截然不同的類型tyle1和type2來說，List<Type1>既不是List<Type2>的子類型，也不是他的超類型。雖然List<String>不是List<Object>的子類型，這與直覺相悖，但是實際上很有意義。你可以將任何對象放進一個List<Object>中，卻只能將字符串放進<String>中。
有時候，我需要的靈活性要比不可變類型所能提供的更多。考慮第26條中的堆棧下面就是他的公共API：
public class Stack<E> {
public Stack();
public void push(E e);
public E pop();
public boolean isEmpty();
}
假設我們想要增加一個方法，讓她按照順序將一系列的元素全部放到堆棧中。這是第一次嘗試，如下：
// pushAll method without wildcard type - deficient;
public void pushAll(Iterable<E> src) {
for (E e: src)
push(e);
}
這個方法編譯的時候正確無誤，但是并非盡如人意，如果Iterable src的元素類型與堆棧的完全匹配，那就沒有問題，但是假如有一個Stack<Number>，并且調用了push(intVal)，這里的intVal就是Integer類型。這是可以的，因為Integer是Number的一個子類型，因此從邏輯上來說，下面這斷代碼應該是可行的：
Stack<Number> numberStack = new Stack<Number>();
Iterable<Integer> integers = ...;
numberStack.pushAll(integers);
但是實際上運行這段代碼會得到錯誤，錯誤如下：
原因在于Iterable<Integer>并不是Iterable<Number>的子類型(參數化類型是不可變的，相應的概念為，數組是協變的)，幸運 的是Java提供了一種解決方法，稱為有限制的通配符類型來處理這種情況。使用有限制的通配符Iterable<? extends E>即可解決這個問題(注意，確定了子類型后，第一個類型便都是自身的子類型)，修改后的程序如下：
// Wildcard type for parameter that serves as an E producer
public void pushAll(Iterable<? extends E> src) {
for (E e: src)
push(e);
}
這么修改了之后，不僅Stack可以正確無誤的編輯，沒有通過初試的pushAll聲明進行編譯的客戶端代碼也一樣可以，因為Stack及其客戶端正無誤的進行了編譯，你就知道一切都是類型安全的了。
對應的，假如我們要編譯一個popAll方法，初次嘗試如下：
// popAll method without wildcart type - deficient;
public void popAll(Collection<E> dst) {
while(!isEmpty())
dst.add(pop());
}
如果目標集合的元素類型與堆棧完全匹配，這段代碼編譯時還是會正確無誤的。運行得很好，但是，也并不意味著盡如人意。假設你有一個Stack<Number>和類型Object變量，如果從堆棧中彈出一個元素，并將它保存在該變量中，它的編譯和運行都不會出錯，考慮如下代碼 ：
Stack<Number> numberStack = new Stack<Number>();
Collection<Object> objects = ...;
numberStack.popAll(objects);
運行這段代碼會得到一個與pushAll第一種情況類似的錯誤:
對于這種情況java同樣提供了一種對應的有限制通配符來解決，popAll的輸入參數類型不應該為“E的集合”，而應該為“E的某種超類的集合”。通配符：Collection<? super E>，根據這種方法修改后的代碼如下：
public void popAll(Collection<? super E> dst) {
while(!isEmpty())
dst.add(pop());
}
由上面這兩種情況可以看出，有限制的通配符類型放寬了檢查的類型，為了獲得最大限度的靈活性，要在表示生產者或者消費者的輸入參數上使用通配符類型。如果某個輸入參數既是生產者，又是消費者，那么通配符類型就沒有什么好處了，因為需要的是嚴格的類型匹配，這是不用任何通配符而得到的。
下面的助記符便于讓你記住要使用哪種通配符類型類型：
**PESC表示producter-extends, consumer-super. **
如果參數化類型表示一個T生產者，就使用<? extends T>；如果它表示一個T消費者，就使用<? super T>。
在我們的Stack實例中，pushAll的src參數產生E實例供Stack使用，因此src相應的類型為Iterable<? extends E>；popAll的dst參數通過Stack消費E實例，因此dst的相應類型為Collection<? super E>。PECS這個助記符突出了使用通配符類型的基本原則。Naftalin和wadler稱之為Get and Put Principle。
下面是第25條中的reduce方法就有這條聲明：
static <E> E reduce(List<E> list, Function<E> f, E initVal){
E[] snapshot = (E[])list.toArray();
E result = initVal;
for (E e:snapshot) {
result = f.apply(result, e);
}
return result;
}
雖然列表既可以消費也可以是、產生值，reduce方法還是只用他的list啊、參數作為E生產者，因此他得聲明就應該使用一個extends E得通配符類型。參數f表示既可以消費又可以產生E實例的函數，因此通配符類型不適合他，得到的聲明如下：
static <E> E reduce(List<? extends E> list, Function<E> f, E initVal);
假設有一個List<Integer>，想通過Function<Number>把他簡化。他不能通過初始聲明進行編譯，但是一旦添加了有限制的通配符類型就可以了。
27條中的union方法：
public static <E> Set<E> union(Set<E> s1, Set<E> s2){
Set<E> result = new HashSet<E>(s1);
result.addAll(s2);
return result;
}
試想一下如下調用：
Set<Integer> integers = ...;
Set<Double> doubles = ...;
Set<Number> numbers = union(integers, doubles);
重寫為:
public static <E> Set<E> union(Set<? extends E> s1, Set<? extends E> s2){
Set<E> result = new HashSet<E>(s1);
result.addAll(s2);
return result;
}
但是實際上，這段代碼中的union方法，編譯器推斷不出需要返回什么類型，所以依然會編譯報錯（1.8不報錯），但是可以顯示指明這一點。
Set<Number> numbers = Union.<Number>union(integers, doubles);
接下來再看27條的max方法：
public static <T extends Comparable<T>> T max(List<T> list){
Iterator<T> i = list.iterator();
T result = i.next();
while (i.hasNext()){
T t = i.next();
if (t.compareTo(result) > 0){
result = t;
}
}
return result;
}
修改過后：
public static <T extends Comparable<? super T>> T max(List<T> list){
Iterator<T> i = list.iterator();
T result = i.next();
while (i.hasNext()){
T t = i.next();
if (t.compareTo(result) > 0){
result = t;
}
}
return result;
}
那么上面這樣復雜的修改真的有用嗎？實際上的確是有用的。
List<ScheduledFuture<?>> scheduledFutures = new ArrayList<>();
在沒有使用有限制通配符時，如果將scheduledFutures 作為參數傳給max方法，會得到如下報錯：
由于ScheduledFuture沒有實現Comparable<ScheduledFuture>借口，相反，他是擴展Comparable<Delayed>接口的Delayed接口的子接口。
在使用了有限制的通配符之后就可以進行比較了。
public interface ScheduledFuture<V> extends Delayed, Future<V> {}
public interface Delayed extends Comparable<Delayed> {}
但是你以為這樣就完了嗎？圖樣圖森破！這段代碼實際上是會編譯報錯的。
他意味著list不是一個List<T>,因此它的iterator方法沒有返回Iterator<T>。他返回的是T的某個子類型的一個iterator，因此要對iterator進行修改：
public static <T extends Comparable<? super T>> T max(List<T> list){
Iterator<? extends T> i = list.iterator();
T result = i.next();
while (i.hasNext()){
T t = i.next();
if (t.compareTo(result) > 0){
result = t;
}
}
return result;
}
這樣迭代器的next方法返回的元素屬于T的某個子類型，因此讓門可以被安全的保存在類型T的一個變量中。
還有一個與通配符有關的話題值得探討。類型參數和通配符之間具有雙重性，許多方法都可以利用其中一個或者另一個進行聲明。例如，下面是可能的兩種靜態方法聲明，來交換列表中的兩個被索引的項目。第一個使用無限制的類型參數，第二個使用無限制的通配符。
// Two possible declarations for the swap method
public static <E> void swap(List<E> list, int i, int j);
public static void swap(List<?> list, int i, int j);
在公共API中第二種方法更好一些，因為它更簡單。一般來說，如果類型參數只在方法聲明中出現一次，就可以用通配符取代它。如果是無限制的類型參數就用無限制的通配符來取代，如果 是有限制的類型參數，就用有限制的通配符來取代。但是，第二種方法存在一個問題，它優先使用通配符而非類型參數，下面的簡單實現都實現不了：
public static void swap(List<?> list, int i, int j) {
list.set(i, list.set(j, list.get(i)));
}
編譯錯誤：
書上的錯誤：
這段代碼編譯時會出錯，我們干了什么？取出元素再放回到表中，為什么這不成功呢？因為list是無限通配符類型List<?>，以前說過，除了null以外的任何對象都無法放入其中。幸運的是，有一種方式可以實現第二種方法，無需求助不安全的轉換或者原始類型。這種想法 就是編寫一個私有輔助方法來捕捉通配符類型。為了捕捉類型，輔助方法必須是泛型方法，因為并不知道通配符代表的具體類型。如下：
public static void swap(List<?> list, int i, int j) {
swapHelper(list, i, j);
}
// Private helper method for wildcard capture
private static <E> void swapHelper(List<E> list, int i, int j) {
list.set(i, list.set(j, list.get(i)));
}
swapHelper方法知道list是List<E>。因此，他知道從這個列表中取出的任何值均為E類型，并知道將E類型的任何值放進列表都是安全的。
總之，在API中使用通配符類型雖然比較需要技巧，但是使API變得靈活的多，如果在寫的是一個將被廣泛使用的類庫，則一定要適當地利用通配符類型，記住基本的原則：PECS，還要記得所有的comparable和comparator都是消費者。
