serialversionuid 默认1L和64位的哈希字段有什么区别

本文目录

• serialversionuid 默认1L和64位的哈希字段有什么区别
• 如何让Android Studio 自动生成 serialVersionUID
• 如何生成serialversionuid
• 如果父类实现了Serializable并生成了serialVersionUID，而子类并没有写重新生成serialVersionUID的语句
• private static final long serialVersionUID=1L 是什么意思
• serialVersionUID有什么作用
• serialVersionUID是什么
• java类中serialversionuid 作用 是什么举个例子说明.
• serialVersionUID 谁能解释下 他是干什么用的

serialversionuid 默认1L和64位的哈希字段有什么区别

区别：

1L这种主要是用于区分系统版本号的，随着版本号的增加，可以改成1、2、3以此类推；

而64位是根据类名、方法、变量等生成的hash值。

1.serialversionuid简介：

相当于java类的身份证。主要用于版本控制。

serialVersionUID作用是序列化时保持版本的兼容性，即在版本升级时反序列化仍保持对象的唯一性。

2.有两种生成方式：

一个是默认的1L，比如：private static final long serialVersionUID = 1L;

一个是根据类名、接口名、成员方法及属性等来生成一个64位的哈希字段。

如何让Android Studio 自动生成 serialVersionUID

设置Android studio实现Serializable自动生成serialVersionUID步骤：
1、File–》Settings–》Editor–》Inspections–》Java–》Serialization issues–》Serializable class without ‘serialVersionUID’ 勾选中该选项即可。
2、进入实现了Serializable中的类，选中类名，Alt+Enter弹出提示，然后直接导入完成

如何生成serialversionuid

今天再看jdk的某些类的时候，突然看到了这个属性变量后面跟着很长的一串数字。以前也接触过这个东西。简单的就知道
为了jkd的版本和用这个类时的所用的jdk编译的版本的一个标识。用于反序列化的。
想用OjbectStreamClass。getSerialVersionID();这个方法打印出来看看也 老是报错；所以用了另一种方式：步骤如下：
1.先写个Test。java类 然后用javac Test编译这个类（这个类是你需要知道那个id的那个类）
public class Test implements java。io。serializable{
public static void main(String args){}}
2.在jdk总，可以用JDK的bin目录下的serialver。exe工具产生这个SerialVersionUID
对于 Test。class 执行命令：serialver Test 即可在dos界面得到这个id了
serialVersionUID 用来表明类的不同版本间的兼容性

如果父类实现了Serializable并生成了serialVersionUID，而子类并没有写重新生成serialVersionUID的语句

父类实现了 Serializable 后，字类不需要显式实现 Serializable，但是仍然需要定义 serialVersionUID。
serialVersionUID 是序列化版本ID，反序列化的时候通过它的值来验证版本是否一致。如果不指明，会根据类的方法属性等信息自动计算出来。
也就是说，序列化之后，如果你没有对子类进行修改，那么是可以正常反序列化的。如果你修改了子类，那么系统自动算出来的 serialVersionUID 就可能发生改变，版本不一致，这时候就不能反序列化了。
手动定义 serialVersionUID 的作用是可以手动控制版本。当你对类进行了修改，自行判断是否和之前兼容，来决定 serialVersionUID 是否修改。

private static final long serialVersionUID=1L 是什么意思

private static final long serialVersionUID=1L意思是定义程序序列化ID。

序列化ID，相当于身份认证，主要用于程序的版本控制，保持不同版本的兼容性，在程序版本升级时避免程序报出版本不一致的错误。

Java的序列化机制是通过在运行时判断类的serialVersionUID来验证版本一致性的。

在进行反序列化时，JVM(推荐进一步了解JVM的结构原理)会把传来的字节流中的serialVersionUID与本地相应实体（类）的serialVersionUID进行比较，如果相同就认为是一致的，可以进行反序列化，否则就会出现序列化版本不一致的异常。

如果没有定义一个名为serialVersionUID，类型为long的变量，Java序列化机制会根据编译的class自动生成一个serialVersionUID，这种情况下，只有同一次编译生成的class才会生成相同的serialVersionUID 。

因为在实际的开发中，重新编译会影响项目进度部署，所以我们为了提高开发效率，不希望通过编译来强制划分软件版本，就需要显式地定义一个名为serialVersionUID，类型为long的变量，不修改这个变量值的序列化实体都可以相互进行串行化和反串行化。

扩展资料

JVM（Java虚拟机）支持的数据类型

基本数据类型

1、byte：1字节有符号整数的补码

2、short：2字节有符号整数的补码

3、int：4字节有符号整数的补码

4、long：8字节有符号整数的补码

5、float：4字节IEEE754单精度浮点数

6、double：8字节IEEE754双精度浮点数

7、char：2字节无符号Unicode字符

8、boolean：boolean数据类型表示一位的信息

其它数据类型

1、object：对一个Javaobject（对象）的4字节引用

2、returnAddress：4字节，用于jsr/ret/jsr-w/ret-w指令

参考资料：百度百科-Java

参考资料：百度百科-序列化

参考资料：百度百科-版本控制

参考资料：百度百科-JVM

serialVersionUID有什么作用

serialVersionUID作用：
序列化时为了保持版本的兼容性，即在版本升级时反序列化仍保持对象的唯一性。
有两种生成方式：
一个是默认的1L，比如：private static final long serialVersionUID = 1L;
一个是根据类名、接口名、成员方法及属性等来生成一个64位的哈希字段，比如：
private static final long serialVersionUID = xxxxL;
当你一个类实现了Serializable接口，如果没有定义serialVersionUID，Eclipse会提供这个
提示功能告诉你去定义 。在Eclipse中点击类中warning的图标一下，Eclipse就会
自动给定两种生成的方式。如果不想定义它，在Eclipse的设置中也
可以把它关掉的，设置如下：
Window ==》 Preferences ==》 Java ==》 Compiler ==》 Error/Warnings ==》
Potential programming problems
将Serializable class without serialVersionUID的warning改成ignore即可。
如果你没有考虑到兼容性问题时，就把它关掉，不过有这个功能是好的，只要任何类别实现了Serializable这个接口的话，如果没有加入
serialVersionUID，Eclipse都会给你warning提示，这个serialVersionUID为了让该类别
Serializable向后兼容。
如果你的类Serialized存到硬盘上面后，可是后来你却更改了类别的field(增加或减少或改名)，当你Deserialize时，就会出现Exception的，这样就会造成不兼容性的问题。
但当serialVersionUID相同时，它就会将不一样的field以type的预设值Deserialize，可避开不兼容性问题。

serialVersionUID是什么

serialVersionUID:意思是序列化的版本号。
【作用】一些java类中为什么需要重载 serialVersionUID 属性。在Java中，软件的兼容性是一个大问题，尤其在使用到对象串行性的时候，那么在某一个对象已经被串行化了，可是这个对象又被修改后重新部署了，那么在这种情况下， 用老软件来读取新文件格式虽然不是什么难事，但是有可能丢失一些信息。serialVersionUID来解决这些问题，新增的serialVersionUID必须定义成下面这种形式：static final long serialVersionUID=-2805284943658356093L;。其中数字后面加上的L表示这是一个long值。 通过这种方式来解决不同的版本之间的串行话问题。
【生成方式】它有两种显示的生成方式：
一个是默认的1L，比如：private static final long serialVersionUID = 1L;。
一个是根据类名、接口名、成员方法及属性等来生成一个64位的哈希字段，比如：private static final long serialVersionUID = xxxxL。

java类中serialversionuid 作用 是什么举个例子说明.

类中影响Serialization进程的特征，两边的操作使用的类版本不同，但它们的 serialVersionUID 必须是一样的。它是用来识别两边的类是否兼容的，两边不同时不应该继续还原状态，而是应该停止下来，因为有人把事情搞错了。如果你的类没有实现 java.io.Serializable 或 java.io.Externalizable，这个字段则没有意义。

如果你没听说过 Java Serialization (序列化，有人书翻译成串行化），那去找些 serialization 介绍看看，下面说的第2段类结构变化时是中级水平的，理解 Java 的一些细节才能理解，多数情况下人们只提到第一种情况(类的结构没有变化时)，也只需要第一种情况。

当Serialization两端(比如Socket两端)使用一个类的不同版本时，我们必须提供 serialVersionUID，它可以用JDK自带的 serialver 命令行来计算:

private static final long serialVersionUID = xxxx ;

如果类中出现了下面两个方法，那么将会被用到，否则使用默认的实现:

private void readObject(ObjectInputStream) throws    IOException,ClassNotFoundException;

private void writeObject(ObjectOutputStream)throws  IOException;

记住这里出现的方法和字段都是 private.

新版本中仅增加了字段或方法而没有改变旧版本中已有的东西时，我们只要保证两个版本中的 serialVersionUID 是一样的就行了.

具体样例可以看 JDK 源码中的像 ArrayList 这些类的代码的 readObject 和 writeObject 方法。

类的结构有些变化时,新版本对旧版本中某些东西进行了删减时, Field 的变化我们需要在readObject和writeObject方法中进行处理

ObjectOutputStream.PutField 类可达到这个目的

只是保证两个版本中的 serialVersionUID 一致是行不通的

类中必需两个常量：

private static final long                serialVersionUID;

private static final ObjectStreamField serialPersistentFields

下面样例是当客户端和服务端使用的类的版本不同并且类的结构也改变了，比如：

对方使用的类 Entry 是：
public class Entry12 ... {
   private String name, email;
   private static final long serialVersionUID = 12L;
}
现在我们改变了类的设计了：
public class Entry12 ... {
   private EntryInternal basic;
   private static final long serialVersionUID = 12L;
   private class EntryInternal {
         private String name, email;
   }
}

 /*  这是一段代码片段，我们假设新版本的类 name & email 两个字段进行了修改
  * (这里我们放到一个内部类EntryInternal 中),而旧版本中直接属于这个类.
  * 
  *  请注意这里的字段和方法的签名, 它们都是 private 的或者是常量.
  */
public class Entry12 implements Serializable {
  private EntryInternal                    pair                   = new EntryInternal();
  /* 这是必要的，因为版本不同 */
  private static final long                serialVersionUID       = 12L;
  ** 这也是必要的，否则写 putFields 时会抛出异常.
   * This field will be used by {@link #writeObject(ObjectOutputStream)},
   * if this field is missing, follwing exception will be threw when invoke 
   * {@link java.io.ObjectOutputStream.PutField#put(String,)} :
   *   an exception ‘java.lang.IllegalArgumentException: No such object field’  will be threw.
   */
  private static final ObjectStreamField serialPersistentFields = new ObjectStreamField {
      new ObjectStreamField(“name“ , String.class),//
      new ObjectStreamField(“email“ , String.class),//  
                                                                  };
 /* 我们在这里不是直接写出字段，而把要写出的字段包装起来，
    我们按需交换字段，而不是直接读写pair 这个字段. 
 */
  private void readObject(ObjectInputStream input) throws IOException, ClassNotFoundException {
    ObjectInputStream.GetField getFields = input.readFields();
    /* 请注意：使用 Serializable 进行交换时不使用构造方法，所以这时 pair 还未初始化. */
    pair = new EntryInternal();
    pair.name = (String) getFields.get(“name“, null);
    pair.email = (String) getFields.get(“email“, null);
  }
  /* 写出时跟读入时一样 */
  private void writeObject(ObjectOutputStream output) throws IOException {
    ObjectOutputStream.PutField putFields = output.putFields();
    putFields.put(“name“, pair == null ? null : pair.name);
    putFields.put(“email“, pair == null ? null : pair.email);
    output.writeFields();
  }
  …..
}

serialVersionUID 谁能解释下 他是干什么用的

serialVersionUID 用来表明类的不同版本间的兼容性
简单来说，Java的序列化机制是通过在运行时判断类的serialVersionUID来验证版本一致性的。在进行反序列化时，JVM会把传来的字节流中的serialVersionUID与本地相应实体（类）的serialVersionUID进行比较，如果相同就认为是一致的，可以进行反序列化，否则就会出现序列化版本不一致的异常。
当实现java.io.Serializable接口的实体（类）没有显式地定义一个名为serialVersionUID，类型为long的变量时，Java序列化机制会根据编译的class自动生成一个serialVersionUID作序列化版本比较用，这种情况下，只有同一次编译生成的class才会生成相同的serialVersionUID 。
如果我们不希望通过编译来强制划分软件版本，即实现序列化接口的实体能够兼容先前版本，未作更改的类，就需要显式地定义一个名为serialVersionUID，类型为long的变量，不修改这个变量值的序列化实体都可以相互进行串行化和反串行化。