zoukankan      html  css  js  c++  java
  • serialVersionUID作用

    原文出处:未知


    Java的序列化机制是通过在执行时推断类的serialVersionUID来验证版本号一致性的。在进行反序列化时,JVM会把传来的字节流中的serialVersionUID与本地对应实体(类)的serialVersionUID进行比較,假设同样就觉得是一致的,能够进行反序列化,否则就会出现序列化版本号不一致的异常。 

    Eclipse中The serializable class XXXXXX does not declare a static final serialVersionUID field of type long出现这种警告处理办法。 

    当採用程序的Add default Serial version ID修复时,Eclipse会加上:private static final long serialVersionUID = 1L; 

    当採用程序的Add generated Serial version ID修复时,Eclipse会加上:private static final long serialVersionUID = xxxxL; 

    事实上这个问题出现的详细原因是和序列化中的这个serialVersionUID有关。 

    serialVersionUID 用来表明类的不同版本号间的兼容性。有两种生成方式: 

    一个是默认的1L,比方:private static final long serialVersionUID = 1L;(相应修复方法1) 

    一个是依据类名、接口名、成员方法及属性等来生成一个64位的哈希字段,比方: 
    private static final long serialVersionUID = xxxxL;(相应修复方法2) 

    在JDK中,能够利用JDK的bin文件夹下的serialver.exe工具产生这个serialVersionUID 的值,对于Test.class,运行命令: 
    serialver Test   这时JVM(java虚拟机)会生成一个哈希字段。 

    对照一下这个哈希字段的值与方法2中生成的字段值是一样的,可见,在CMD中使用serialver指令就是依据类名、接口名、成员方法及属性等来生成哈希字段的。 

    以下来讨论java类中为什么须要重载 serialVersionUID 属性。 

    当两个进程在进行远程通信时,彼此能够发送各种类型的数据。不管是何种类型的数据,都会以二进制序列的形式在网络上传送。发送方须要把这个Java对象转换为字节序列,才干在网络上传送;接收方则须要把字节序列再恢复为Java对象。 

      把Java对象转换为字节序列的过程称为对象的序列化。 

      把字节序列恢复为Java对象的过程称为对象的反序列化。 

      对象的序列化主要有两种用途: 

      1) 把对象的字节序列永久地保存到硬盘上,通常存放在一个文件里; 

      2) 在网络上传送对象的字节序列。 

    java.io.ObjectOutputStream代表对象输出流,它的writeObject(Object obj)方法可对參数指定的obj对象进行序列化,把得到的字节序列写到一个目标输出流中。 

    java.io.ObjectInputStream代表对象输入流,它的readObject()方法从一个源输入流中读取字节序列,再把它们反序列化为一个对象,并将其返回。 

    仅仅有实现了Serializable和Externalizable接口的类的对象才干被序列化。Externalizable接口继承自Serializable接口,实现Externalizable接口的类全然由自身来控制序列化的行为,而仅实现Serializable接口的类能够採用默认的序列化方式 。 

    凡是实现Serializable接口的类都有一个表示序列化版本号标识符的静态变量:private static final long serialVersionUID; 

    类的serialVersionUID的默认值全然依赖于Java编译器的实现,对于同一个类,用不同的Java编译器编译,有可能会导致不同的serialVersionUID,也有可能同样。为了提高serialVersionUID的独立性和确定性,强烈建议在一个可序列化类中显示的定义serialVersionUID,为它赋予明白的值。显式地定义serialVersionUID有两种用途: 

      1)在某些场合,希望类的不同版本号对序列化兼容,因此须要确保类的不同版本号具有同样的serialVersionUID;在某些场合,不希望类的不同版本号对序列化兼容,因此须要确保类的不同版本号具有不同的serialVersionUID。 

      2)当你序列化了一个类实例后,希望更改一个字段或加入�一个字段,不设置serialVersionUID,所做的不论什么更改都将导致无法反序化旧有实例,并在反序列化时抛出一个异常。假设你加入�了serialVersionUID,在反序列旧有实例时,新加入�或更改的字段值将设为初始化值(对象为null,基本类型为对应的初始默认值),字段被删除将不设置。 

    当系统不须要序列化类时,能够去掉这些警告,做例如以下设置:Window-->Preferences-->Java,将serializable class without serialVersionUID的设置由warning改为Ignore。然后Eclipse会又一次编译程序,那些警告信息也就消失了。 

    struts架构下的站点常常出现javax.servlet.ServletException: BeanUtils.populate 错误,可是本地执行又一切正常,唯一认为可能产生问题的就是server上跑了好几个站点,都是一样的架构的,怀疑是不是web容器把几个项目之间的java类给共用了,考虑到非常多类都定义了serialVersionUID字段,然后尝试删除了某个类的serialVersionUID,结果关于该类的操作就恢复正常了。网上简单查阅了一下资料,感觉是tomcat把全部类串行化时候,因为我们的几个项目非常多java类都是复制粘贴的,所以导致了非常多类的serialVersionUID都是同一个值,所以tomcat会把不同项目的同样类名的类当作同一个类去处理,导致了这个奇怪的错误。 

    解决方式: 
    每一个项目同名的类serialVersionUID改为不一样,不能直接的复制粘贴过来。

  • 相关阅读:
    temp12
    temp111
    test.c
    vipLogin.c
    services.c
    request.c
    managerLogin.c
    将博客搬至CSDN
    SpringMabatis整合项目mybatis-configuration.xml核心配置
    logback-test.xml配置文件模板
  • 原文地址:https://www.cnblogs.com/yxwkf/p/4025769.html
Copyright © 2011-2022 走看看