要理解字段serialVersionUID的重要性，应该了解序列化/反序列化的工作原理。

当序列化一个Serializable类对象时，Java Runtime将一个序列版本号（称为serialVersionUID）与这个序列化对象相关联。在反序列化此序列化对象时，Java Runtime将序列化对象的serialVersionUID与类的serialVersion UID匹配。如果两者都相等，则只有它继续执行进一步的反序列化过程，否则抛出InvalidClassException。

因此，我们得出结论，要使序列化/反序列化过程成功，序列化对象的serialVersionUID必须与类的serialVersion UID等效。如果程序员在程序中显式指定serialVersionUID值，那么无论序列化和反序列化平台如何，相同的值都将与序列化对象和类相关联（例如，可以使用sun或MS JVM在类似windows的平台上进行序列化，而反序列化可以使用Zing JVM在不同的平台Linux上进行）。

但是，如果程序员未指定serialVersionUID，则在对任何对象进行Serialization\DeSerialization时，Java运行时会使用自己的算法来计算它。这种serialVersionUID计算算法因JRE而异。对象序列化的环境也可能使用一个JRE（例如：SUN JVM），而取消序列化的环境则使用LinuxJvm（zing）。在这种情况下，与序列化对象关联的serialVersionUID将不同于在取消序列化环境中计算的类的serialVersion UID。反过来，反序列化将不会成功。所以为了避免这种情况/问题，程序员必须始终指定Serializable类的serialVersionUID。

您可以告诉Eclipse忽略这些serialVersionUID警告：

窗口>首选项>Java>编译器>错误/警告>潜在编程问题

如果您不知道，您可以在本节中启用许多其他警告（甚至将一些警告报告为错误），其中许多警告非常有用：

潜在的编程问题：可能的意外布尔赋值潜在编程问题：空指针访问不必要的代码：从不读取局部变量不必要的代码：冗余空检查不必要的代码：不必要的强制转换或“instanceof”

以及更多。

什么是serialVersionUID，为什么要使用它？

SerialVersionUID是每个类的唯一标识符，JVM使用它来比较类的版本，以确保在序列化期间使用的相同类在反序列化期间加载。

指定一个可以提供更多控制，但如果不指定，JVM会生成一个。不同编译器生成的值可能不同。此外，有时您只是出于某种原因想要禁止旧序列化对象的反序列化[向后不兼容]，在这种情况下，您只需更改serialVersionUID。

Serializable的javadocs表示：

默认的serialVersionUID计算对类高度敏感详细信息可能因编译器实现而异因此，在反序列化。

因此，您必须声明serialVersionUID，因为它给了我们更多的控制权。

这篇文章在这个话题上有一些好的观点。

首先我需要解释什么是序列化。

序列化允许将对象转换为流，以便通过网络发送该对象或将其保存到文件或保存到DB中以供字母使用。

序列化有一些规则。

只有当对象的类或其超类实现serializable接口时，对象才可串行化对象是可序列化的（它本身实现了可序列化接口），即使它的超类不是。但是，可序列化类层次结构中的第一个超类（未实现可序列化接口）必须具有无参数构造函数。如果违反了这一点，readObject（）将在运行时生成java.io.InvalidClassException所有基元类型都是可序列化的。瞬态字段（带有瞬态修饰符）未序列化（即未保存或还原）。实现Serializable的类必须标记不支持序列化的类的临时字段（例如，文件流）。静态字段（带有静态修饰符）未序列化。

当Object被序列化时，Java Runtime将序列版本号（即serialVersionID）关联起来。

我们需要serialVersionID的地方：

在反序列化期间，验证发送方和接收方在序列化方面是否兼容。如果接收方使用不同的serialVersionID加载了类，则反序列化将以InvalidClassCastException结束。可序列化类可以通过声明一个名为serialVersionUID的字段来显式声明自己的serialVersionID，该字段必须是静态、final和long类型。

让我们举个例子来试试。

import java.io.Serializable;

public class Employee implements Serializable {
    private static final long serialVersionUID = 1L;
    private String empname;
    private byte empage;

    public String getEmpName() {
        return name;
    }

    public void setEmpName(String empname) {
        this.empname = empname;
    }

    public byte getEmpAge() {
        return empage;
    }

    public void setEmpAge(byte empage) {
        this.empage = empage;
    }

    public String whoIsThis() {
        return getEmpName() + " is " + getEmpAge() + "years old";
    }
}

创建序列化对象

import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectOutputStream;

public class Writer {
    public static void main(String[] args) throws IOException {
        Employee employee = new Employee();
        employee.setEmpName("Jagdish");
        employee.setEmpAge((byte) 30);

        FileOutputStream fout = new
                FileOutputStream("/users/Jagdish.vala/employee.obj");
        ObjectOutputStream oos = new ObjectOutputStream(fout);
        oos.writeObject(employee);
        oos.close();
        System.out.println("Process complete");
    }
}

反序列化对象

import java.io.FileInputStream;
import java.io.IOException;
import java.io.ObjectInputStream;

public class Reader {
    public static void main(String[] args) throws ClassNotFoundException, IOException {
        Employee employee = new Employee();
        FileInputStream fin = new FileInputStream("/users/Jagdish.vala/employee.obj");
        ObjectInputStream ois = new ObjectInputStream(fin);
        employee = (Employee) ois.readObject();
        ois.close();
        System.out.println(employee.whoIsThis());
    }
}

注意：现在更改Employee类的serialVersionUID并保存：

private static final long serialVersionUID = 4L;

并执行Reader类。不执行Writer类，您将得到异常。

Exception in thread "main" java.io.InvalidClassException: 
com.jagdish.vala.java.serialVersion.Employee; local class incompatible: 
stream classdesc serialVersionUID = 1, local class serialVersionUID = 4
at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:616)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1623)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1518)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1774)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1351)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:371)
at com.krishantha.sample.java.serialVersion.Reader.main(Reader.java:14)

我不能错过这个机会，插上乔什·布洛克（Josh Bloch）的书《有效的Java》（第二版）。第10章是关于Java序列化的不可或缺的资源。

根据Josh的说法，自动生成的UID是基于类名、实现的接口以及所有公共和受保护的成员生成的。以任何方式更改任何这些都将更改serialVersionUID。因此，只有当您确定不会有多个版本的类被串行化（跨进程或稍后从存储中检索）时，才不需要使用它们。

如果您现在忽略它们，然后发现需要以某种方式更改类，但保持与旧版本类的兼容性，则可以使用JDK工具serialver在旧类上生成serialVersionUID，并在新类上显式设置。（根据您的更改，您可能还需要通过添加writeObject和readObject方法来实现自定义序列化-请参阅Serializable javadoc或上述第10章。）

如果您序列化只是因为为了实现而必须序列化（例如，谁会关心您是否为HTTPSession序列化……如果它是否存储，您可能不关心对表单对象进行反序列化），那么您可以忽略这一点。

如果您实际使用的是序列化，那么只有计划直接使用序列化存储和检索对象时才重要。serialVersionUID表示类的版本，如果类的当前版本与其前一版本不向后兼容，则应递增该版本。

大多数时候，您可能不会直接使用序列化。如果是这种情况，请通过单击快速修复选项生成默认的SerialVersionUID，不用担心。