它与case类和class类似，当没有任何字段表示额外的状态信息时，我们只是使用case对象而不是case类。

一个巨大的死灵，但这是最高的结果在谷歌之外的官方教程，一如既往，是相当模糊的细节。下面是一些基本对象:

object StandardObject

object SerializableObject extends Serializable

case object CaseObject

现在，让我们使用IntelliJ在编译的.class文件上“将Scala反编译为Java”的非常有用的特性:

//decompiled from StandardObject$.class
public final class StandardObject$ {
   public static final StandardObject$ MODULE$ = new StandardObject$();

   private StandardObject$() {
   }
}

//decompiled from StandardObject.class
import scala.reflect.ScalaSignature;

@ScalaSignature(<byte array string elided>)

public final class StandardObject {
}

正如您所看到的，这是一个非常简单的单例模式，除了这个问题范围之外的原因，生成了两个类:静态的StandardObject(如果对象定义了任何静态转发器方法，它将包含静态转发器方法)和实际的单例实例StandardObject$，其中代码中定义的所有方法最终都是实例方法。当你实现Serializable时，事情变得更有趣:

//decompiled from SerializableObject.class
import scala.reflect.ScalaSignature;

@ScalaSignature(<byte array string elided>)
public final class SerializableObject {
}

        //decompiled from SerializableObject$.class
import java.io.Serializable;
import scala.runtime.ModuleSerializationProxy;

public final class SerializableObject$ implements Serializable {
   public static final SerializableObject$ MODULE$ = new SerializableObject$();

   private Object writeReplace() {
      return new ModuleSerializationProxy(SerializableObject$.class);
   }

   private SerializableObject$() {
   }
}

The compiler doesn't limit itself to simply making the 'instance' (non-static) class Serializable, it adds a writeReplace method. writeReplace is an alternative to writeObject/readObject; what it does, it serializes a different object whenether the Serializable class having this method is being serialized. On deserializention then, that proxy object's readResolve method is invoked once it is deserialized. Here, a ModuleSerializableProxy instance is serialized with a field carrying the Class[SerializableObject], so it knows what object needs to be resolved. The readResolve method of that class simply returns SerializableObject - as it is a singleton with a parameterless constructor, scala object is always structurally equal to itself between diffrent VM instances and different runs and, in this way, the property that only a single instance of that class is created per one VM instance is preserved. A thing of note is that there is a security hole here: no readObject method is added to SerializableObject$, meaning an attacker can maliciously prepare a binary file which matches standard Java serialization format for SerializableObject$ and a separate instance of the 'singleton' will be created.

现在，让我们移动到case对象:

//decompiled from CaseObject.class
import scala.collection.Iterator;
import scala.reflect.ScalaSignature;

@ScalaSignature(<byte array string elided>)
public final class CaseObject {
   public static String toString() {
      return CaseObject$.MODULE$.toString();
   }

   public static int hashCode() {
      return CaseObject$.MODULE$.hashCode();
   }

   public static boolean canEqual(final Object x$1) {
      return CaseObject$.MODULE$.canEqual(var0);
   }

   public static Iterator productIterator() {
      return CaseObject$.MODULE$.productIterator();
   }

   public static Object productElement(final int x$1) {
      return CaseObject$.MODULE$.productElement(var0);
   }

   public static int productArity() {
      return CaseObject$.MODULE$.productArity();
   }

   public static String productPrefix() {
      return CaseObject$.MODULE$.productPrefix();
   }

   public static Iterator productElementNames() {
      return CaseObject$.MODULE$.productElementNames();
   }

   public static String productElementName(final int n) {
      return CaseObject$.MODULE$.productElementName(var0);
   }
}

        //decompiled from CaseObject$.class
import java.io.Serializable;
import scala.Product;
import scala.collection.Iterator;
import scala.runtime.ModuleSerializationProxy;
import scala.runtime.Statics;
import scala.runtime.ScalaRunTime.;

public final class CaseObject$ implements Product, Serializable {
   public static final CaseObject$ MODULE$ = new CaseObject$();

   static {
      Product.$init$(MODULE$);
   }

   public String productElementName(final int n) {
      return Product.productElementName$(this, n);
   }

   public Iterator productElementNames() {
      return Product.productElementNames$(this);
   }

   public String productPrefix() {
      return "CaseObject";
   }

   public int productArity() {
      return 0;
   }

   public Object productElement(final int x$1) {
      Object var2 = Statics.ioobe(x$1);
      return var2;
   }

   public Iterator productIterator() {
      return .MODULE$.typedProductIterator(this);
   }

   public boolean canEqual(final Object x$1) {
      return x$1 instanceof CaseObject$;
   }

   public int hashCode() {
      return 847823535;
   }

   public String toString() {
      return "CaseObject";
   }

   private Object writeReplace() {
      return new ModuleSerializationProxy(CaseObject$.class);
   }

   private CaseObject$() {
   }
}

A lot more is going on, as CaseObject$ now implements also Product0, with its iterator and accessor methods. I am unaware of a use case for this feature, it is probably done for consistency with case class which is always a product of its fields. The main practical difference here is that we get canEqual, hashCode and toString methods for free. canEqual is relevant only if you decide to compare it with a Product0 instance which is not a singleton object, toString saves us from implementing a single simple method, which is useful when case objects are used as enumeration constants without any behaviour implemented. Finally, as one might suspect, hashCode returns a constant, so it is the same for all VM instances. This matters if one serializes some flawed hash map implementation, but both standard java and scala hash maps wisely rehash all contents on deserialization, so it shouldn't matter. Note that equals is not overriden, so it is still reference equality, and that the security hole is still there. A huge caveat here: if a case object inherit equals/toString from some supertype other than Object, the corresponding methods are not generated, and the inherited definitions are used instead.

TL;DR:在实践中唯一重要的区别是toString返回对象的非限定名称。

不过，我必须在这里声明:我不能保证编译器除了字节码中的实际内容外，不会特别处理case对象。当模式匹配case类时当然会这样做，除了它们实现unapply之外。

case对象隐式地带有方法toString、equals和hashCode的实现，但简单对象没有。 case对象可以序列化，而简单对象不能，这使得case对象作为Akka-Remote的消息非常有用。 在object关键字之前添加case关键字使对象可序列化。

这里有一个区别——case对象扩展了Serializable特性，所以它们可以被序列化。默认情况下，常规对象不能:

scala> object A
defined module A

scala> case object B
defined module B

scala> import java.io._
import java.io._    

scala> val bos = new ByteArrayOutputStream                                            
bos: java.io.ByteArrayOutputStream =  

scala> val oos = new ObjectOutputStream(bos)                                          
oos: java.io.ObjectOutputStream = java.io.ObjectOutputStream@e7da60                   

scala> oos.writeObject(B)

scala> oos.writeObject(A)
java.io.NotSerializableException: A$

Case类与常规类的不同之处在于:

模式匹配支持 equals和hashCode的默认实现 序列化的默认实现 toString的一个更漂亮的默认实现，以及 它们从scala.Product中自动继承的少量功能。

模式匹配、equals和hashCode对于单例来说并不重要(除非你做了一些真正退化的事情)，所以你基本上只是得到了序列化、一个漂亮的toString和一些你可能永远不会使用的方法。

它与case类和class类似，当没有任何字段表示额外的状态信息时，我们只是使用case对象而不是case类。