@responseBody + 序列化

为什么转载@responseBody这个注解的博客呢？因为我在看序列化的时候，就在考虑，Spring中使用@responseBody的Json序列化，为啥不用最常用的Serializable序列化呢？直接转换为二进制流不好吗？？？

先说@responseBody

1、@responseBody注解的作用是将controller的方法返回的对象通过适当的转换器转换为指定的格式之后，写入到response对象的body区，通常用来返回JSON数据或者是XML数据，需要注意的呢，在使用此注解之后不会再走试图处理器，而是直接将数据写入到输入流中，他的效果等同于通过response对象输出指定格式的数据。

2、使用

　　@RequestMapping("/login")
　　@ResponseBody
　　public User login(User user){
　　　　return user;
　　}

User字段：userName pwd 那么在前台接收到的数据为：'{"userName":"xxx","pwd":"xxx"}'

效果等同于如下代码：

　　@RequestMapping("/login")
　　public void login(User user, HttpServletResponse response){
　　　　response.getWriter.write(JSONObject.fromObject(user).toString());
　　}

 

再说序列化

什么是序列化？

内存中的数据对象只有转换为二进制流才可以进行数据持久化和网络传输。将数据对象转换为二进制流的过程称为对象的序列化（Serialization）。反之，将二进制流恢复为数据对象的过程称为反序列化（Deserialization）。序列化需要保留充分的信息以恢复数据对象，但是为了节约存储空间和网络带宽，序列化后的二进制流又要尽可能小。序列化常见的使用场景是RPC框架的数据传输。

1.Java原生序列化

• Java类通过实现Serializable接口来实现该类对象的序列化，这个接口非常特殊，没有任何方法，只起标识作用.Java序列化保留了对象类的元数据（如类、成员变量、继承类信息等），以及对象数据等，兼容性最好，但不支持跨语言，而且性能一般。
• 实现Serializable接口的类建议设置serialVersionUID字段值，如果不设置，那么每次运行时，编译器会根据类的内部实现，包括类名、接口名、方法和属性等来自动生成serialVersionUID。如果类的源代码有修改，那么重新编译后serial VersionUID的取值可能会发生变化。因此实现Serializable接口的类一定要显式地定义serialVersionUID属性值。修改类时需要根据兼容性决定是否修改serialVersionUID值：
• 1.如果是兼容升级，请不要修改serialVersionUID字段，避免反序列化失败。
• 2.如果是不兼容升级，需要修改serialVersionUID值，避免反序列化混乱。
• 使用Java原生序列化需注意，Java反序列化时不会调用类的无参构造方法，而是调用native方法将成员变量赋值为对应类型的初始值。基于性能及兼容性考虑，不推荐使用Java 原生序列化。

2.Json序列化

• JSON ( JavaScript O同ect Notation ）是一种轻量级的数据交换格式。
• JSON 序列化就是将数据对象转换为 JSON 字符串。
• 在序列化过程中抛弃了类型信息，所以反序列化时只有提供类型信息才能准确地反序列化。
• 相比前两种方式，JSON 可读性比较好，方便调试。
• 序列化通常会通过网络传输对象 ， 而对象中往往有敏感数据，所以序列化常常成为黑客的攻击点，攻击者巧妙地利用反序列化过程构造恶意代码，使得程序在反序列化的过程中执行任意代码。 Java 工程中广泛使用的 Apache Commons Collections 、Jackson 、 fastjson 等都出现过反序列化漏洞。如何防范这种黑客攻击呢？有些对象的敏感属性不需要进行序列化传输 ，可以加 transient 关键字，避免把此属性信息转化为序列化的二进制流。如果一定要传递对象的敏感属性，可以使用对称与非对称加密方
• 式独立传输，再使用某个方法把属性还原到对象中。应用开发者对序列化要有一定的安全防范意识 ， 对传入数据的内容进行校验或权限控制，及时更新安全漏洞，避免受到攻击。