ITEM 89:使用枚举而不是 readResolve

ITEM 89: FOR INSTANCE CONTROL, PREFER ENUM TYPES TOREADRESOLVE
  item 3 描述了单例模式,并给出了下面的单例类示例。这个类限制对其构造函数的访问,以确保只创建一个实例:

public class Elvis {
  public static final Elvis INSTANCE = new Elvis(); 
  private Elvis() { ... }
  public void leaveTheBuilding() { ... } }

  如 item 3 所述,如果将实现 Serializable 的单词添加到它的声明中,这个类将不再是一个单例。类使用默认的序列化形式还是自定义序列化形式(item 87)并不重要,类是否提供显式的 readObject 方法(item 88)也不重要。
  任何 readObject 方法,无论是显式的还是默认的,都会返回一个新创建的实例,它将不是在类初始化时创建的相同实例。
  readResolve 特性允许您用另一个实例替换由 readObject [Serialization, 3.7]创建的实例。如果正在反序列化的对象的类使用适当的声明定义了一个 readResolve 方法,则在反序列化后在新创建的对象上调用该方法。然后,该方法返回的对象引用将代替新创建的对象返回。在此特性的大多数使用中,不会保留对新创建对象的引用,因此它立即符合垃圾收集的条件。
如果 Elvis 类被用来实现 Serializable,下面的读取-解析方法足以保证单例属性:

// readResolve for instance control - you can do better!
private Object readResolve() {
  // Return the one true Elvis and let the garbage collector 
  // take care of the Elvis impersonator.
  return INSTANCE;
}

  此方法忽略反序列化的对象,返回在初始化类时创建的 Elvis 实例。因此,Elvis 实例的序列化形式不需要包含任何实际数据;所有实例字段都应该声明为 transient。实际上,如果您依赖于 readResolve 进行实例控制,那么具有对象引用类型的所有实例字段都必须声明为 transient。否则,一个确定的攻击者可能会在反序列化对象的readResolve 方法运行之前保护对其的引用,使用的技术有点类似于item 88 中的MutablePeriod 攻击。
  这种攻击有点复杂,但基本原理很简单。如果一个单例包含一个非瞬态对象引用字段,该字段的内容将在该单例的 readResolve 方法运行之前被反序列化。这允许一个精心设计的流在对象引用字段的内容被反序列化时“偷取”一个对最初反序列化的单例的引用。
  下面是它的工作原理。首先,编写一个 “stealer” 类,该类拥有一个 readResolve 方法和一个实例字段,该实例字段引用了被 stealer “隐藏”的序列化单例。在序列化流中,用 stealer 的实例替换 singleton 的非瞬态字段。现在就有了一个循环:单元素包含偷取者,偷取者引用单元素。
  因为单例包含窃取器,所以窃取器的 readResolve 方法在反序列化单例时首先运行。因此,当 stealer 的 readResolve 方法运行时,它的实例字段仍然引用部分反序列化(还没有解析)的单例。
  stealer 的 readResolve 方法将引用从它的实例字段复制到一个静态字段中,以便在readResolve 方法运行后可以访问该引用。然后,该方法为其隐藏的字段返回正确类型的值。如果不这样做,那么当序列化系统试图将 stealer 引用存储到这个字段时,VM 将抛出 ClassCastException。
  为了使其具体化,考虑以下破碎单例:

// Broken singleton - has nontransient object reference field!
public class Elvis implements Serializable {
  public static final Elvis INSTANCE = new Elvis(); 
  private Elvis() { }
  private String[] favoriteSongs = { "Hound Dog", "Heartbreak Hotel" };
  public void printFavorites() { 
    System.out.println(Arrays.toString(favoriteSongs));
  }
  private Object readResolve() { 
    return INSTANCE;
  } 
}

  下面是一个“stealer”,按照上面的描述构造:

public class ElvisStealer implements Serializable { 
  static Elvis impersonator;
  private Elvis payload;
  private Object readResolve() {
    // Save a reference to the "unresolved" Elvis instance
    impersonator = payload;
    // Return object of correct type for favoriteSongs field
    return new String[] { "A Fool Such as I" }; 
  }
  private static final long serialVersionUID = 0; 
}

  最后,这里有一个丑陋的程序,它反序列化一个手工生成的流,以生成有缺陷的单例的两个不同实例。反序列化方法从这个程序中被省略了,因为它与第354页上的方法相同:

public class ElvisImpersonator {
  // Byte stream couldn't have come from a real Elvis instance!
  private static final byte[] serializedForm = {
(byte)0xac, (byte)0xed, 0x00, 0x05, 0x73, 0x72, 0x00, 0x05, 0x45, 0x6c, 0x76, 0x69, 0x73, (byte)0x84, (byte)0xe6, (byte)0x93, 0x33, (byte)0xc3, (byte)0xf4, (byte)0x8b, 0x32, 0x02, 0x00, 0x01, 0x4c, 0x00, 0x0d, 0x66, 0x61, 0x76, 0x6f, 0x72, 0x69, 0x74, 0x65, 0x53, 0x6f, 0x6e, 0x67, 0x73, 0x74, 0x00, 0x12, 0x4c, 0x6a, 0x61, 0x76, 0x61, 0x2f, 0x6c, 0x61, 0x6e, 0x67, 0x2f, 0x4f, 0x62, 0x6a, 0x65, 0x63, 0x74, 0x3b, 0x78, 0x70, 0x73, 0x72, 0x00, 0x0c, 0x45, 0x6c, 0x76, 0x69, 0x73, 0x53, 0x74, 0x65, 0x61, 0x6c, 0x65, 0x72, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x01, 0x4c, 0x00, 0x07, 0x70, 0x61, 0x79, 0x6c, 0x6f, 0x61, 0x64, 0x74, 0x00, 0x07, 0x4c, 0x45, 0x6c, 0x76, 0x69, 0x73, 0x3b, 0x78, 0x70, 0x71, 0x00, 0x7e, 0x00, 0x02};
  public static void main(String[] args) {
    // Initializes ElvisStealer.impersonator and returns // the real Elvis (which is Elvis.INSTANCE)
    Elvis elvis = (Elvis) deserialize(serializedForm); 
    Elvis impersonator = ElvisStealer.impersonator;
    elvis.printFavorites();
    impersonator.printFavorites(); 
  }
}

  运行这个程序会产生以下输出,最终证明有可能创建两个不同的 Elvis 实例(具有不同的音乐品味):

[Hound Dog, Heartbreak Hotel] 
[A Fool Such as I]

  你可以解决这个问题通过声明 favoriteSongs 为 transient, 但你最好解决它通过使 Elvis 成为一个蛋元素的 enum类型(item 3)。ElvisStealer 为代表的攻击,使用readResolve 方法防止“临时”反序列化实例被攻击者访问是脆弱的,需要非常小心。
  如果您将可序列化的实例控制类编写为枚举,Java 保证除了声明的常量之外不存在任何实例,除非攻击者滥用了可访问的特权方法(如AccessibleObject.setAccessible)。任何可以这样做的攻击者已经有足够的特权来执行任意的本地代码,所有的赌注都是无效的。

// Enum singleton - the preferred approach
public enum Elvis {
  INSTANCE;
  private String[] favoriteSongs = { "Hound Dog", "Heartbreak Hotel" }; 
  public void printFavorites() {
    System.out.println(Arrays.toString(favoriteSongs)); 
  }
}

  对实例控件使用 readResolve 并没有过时。如果必须编写一个可序列化的实例控制类,其实例在编译时是未知的,则不能将该类表示为 enum 类型。
  readResolve 的可访问性很重要。如果在 final 类上放置一个 readResolve 方法,那么它应该是私有的。如果将 readResolve 方法放在非 final 类上,则必须仔细考虑其可访问性。如果它是私有的,它将不适用于任何子类。如果它是包私有的,它将只应用于同一包中的子类。如果它是受保护的或公共的,它将应用于所有不覆盖它的子类。如果 readResolve 方法是受保护的或公共的,而子类没有覆盖它,那么反序列化子类实例将产生超类实例,这可能会导致 ClassCastException 异常。
  总之,请尽可能使用枚举类型来强制实例控制不变量。如果这是不可能的,并且您需要一个既可序列化又受实例控制的类,那么您必须提供一个 readResolve 方法,并确保类的所有实例字段都是原语或瞬态字段。

你可能感兴趣的:(ITEM 89:使用枚举而不是 readResolve)