Effective Java: For Instance Control, Prefer Enum types to readResolve

Effective Java Review (90 Part Series)

In a previous section, we discussed different ways to make singleton objects in Java. One of the methods we discussed followed the following pattern:

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

  public void leaveTheBuilding() { ... }
}

Enter fullscreen mode Exit fullscreen mode

By making the constructor private we prevent unexpected creations of the Elvis object. The problem with this pattern is that if you add implements Serializable to the class we open ourselves up for bypassing the private constructor. As has been mentioned in previous chapters, serialization effectively introduces a new, system-provided, constructor.

The built-in functionality to handle this issue and to take back some control of the instances produced by a class is the readResolve function. This function allows the substitution of another instance in place of the one created by readObject. If your class defines a readResolve function with the proper signature it will be invoked after the readObject function. The reference returned by this method will then be returned in place of the newly created object. In common usage, no reference to the newly created object is retained and thus it can be garbage collected.

Using this functionality to sure up our above Elvis class could end up looking something like the following:

private Object readResolve() {
  return INSTANCE;
}

Enter fullscreen mode Exit fullscreen mode

This ends up being pretty straightforward in this case, rather than do anything with the newly created object we simply return our one true Elvis instance. Since no data from the serialization is used we can, and should declare all instance fields as transient. If you have instance fields that are object reference types then you must declare them transient to avoid a possible attack where an attacker could get a hold of the deserialized object before it is garbage collected and thus can keep it around resulting in your singleton no longer being a singleton.

The particular steps of this attack aren’t strictly necessary to understand. Interested readers are encouraged to read the source material. Suffice to say it is possible by creating a “stealer” class that causes a circular dependency with the deserialized object and thus avoiding garbage collection can be made. While not a likely attack, it is better to be safe than sorry.

While declaring all fields as transient is one method of avoiding this issue, there are other ways to accomplish it as well. Another pattern from our previous singleton chapter used a single-element enum type to facilitate the singleton. This puts much of the singleton safety semantics on the JVM to perform and releases you from that burden. Our example as an enum type would be:

public enum Elvis {
  INSTANCE;

  private String[] favoriteSongs = { "Hound Dog", "Heartbreak Hotel" }
  public void printFavorites() {
    System.out.println(Arrays.toString(favoriteSongs));
  }
}

Enter fullscreen mode Exit fullscreen mode

readResolve still may be necessary even with the above pattern when the instances of a class are not known at compile time.

Another thing to note when using the readResolve function is the visibility of the method. If your class is final then readResolve should be private. If your class is non-final you have more options. If you make it private it will not do any instance control for subclasses. If it is package-private it will only apply to subclasses that live in the same package. Finally, if you make it protected or public and a subclass doesn’t override it any deserialization of the class will create an instance of the super class, not the subclass, which will likely cause a ClassCastException.

In summary, the use of enum type singletons should be preferred whenever possible when trying to enforce instance control on a serializable class. If it is not possible to use the enum pattern then careful consideration needs to be taken when writing the class’s readResolve method. You should make sure that all the class’s instance fields are either primitive or marked transient to protect against potential attacks against your instance control mechanism.

Effective Java Review (90 Part Series)

原文链接：Effective Java: For Instance Control, Prefer Enum types to readResolve

文章版权声明 1、本网站名称：拾光赋
2、本站永久网址：https://www.blogs.ink
3、本网站的文章部分内容可能来源于网络，仅供大家学习与参考，如有侵权，请联系站长QQ：805375623进行删除处理。
4、本站一切资源不代表本站立场，并不代表本站赞同其观点和对其真实性负责。
5、本站一律禁止以任何方式发布或转载任何违法的相关信息，访客发现请向站长举报
6、本站资源大多存储在云盘，如发现链接失效，请联系我们我们会第一时间更新。

THE END