serializar - ¿Cómo funciona la serialización de Java y cuándo se debe usar en lugar de otra técnica de persistencia?
serialización en netbeans (9)
Últimamente trato de aprender más y generalmente pruebo la serialización de Java para proyectos personales y de trabajo, y debo decir que cuanto más lo sé, menos me gusta. Esto puede ser causado por información errónea, así que es por eso que les estoy pidiendo estas dos cosas a todos ustedes:
1: En el nivel de bytes, ¿cómo sabe la serialización cómo hacer coincidir los valores serializados con alguna clase?
Uno de mis problemas aquí es que realicé una pequeña prueba con ArrayList que contenía los valores "uno", "dos", "tres". Después de la serialización, la matriz de bytes tomó 78 bytes, lo que parece muchísimo para una cantidad tan baja de información (19 + 3 + 3 + 4 bytes). De acuerdo, es probable que haya algunos gastos generales, pero esto lleva a mi segunda pregunta:
2: ¿Se puede considerar la serialización como un buen método para persistir en absoluto? Ahora, obviamente, si utilizara algún formato XML casero, los datos de persistencia serían algo como esto
<object>
<class="java.util.ArrayList">
<!-- Object array inside Arraylist is called elementData -->
<field name="elementData">
<value>One</value>
<value>Two</value>
<value>Three</value>
</field>
</object>
que, como XML en general, está un poco hinchado y toma 138 bytes (sin espacios en blanco, eso es). Lo mismo en JSON podría ser
{
"java.util.ArrayList": {
"elementData": [
"one",
"two",
"three"
]
}
}
que es de 75 bytes, por lo que es un poco más pequeño que la serialización de Java. Con estos formatos basados en texto, es obvio que tiene que haber una forma de representar sus datos básicos como texto, números o cualquier combinación de ambos.
Entonces, para recapitular, ¿cómo funciona la serialización en el nivel byte / bit, cuándo se debe usar y cuándo no se debe usar y cuáles son los beneficios reales de la serialización, además de que viene de serie en Java?
¿Cómo funciona la serialización incorporada de Java?
Cuando queremos serializar un objeto, implementamos la interfaz java.io.Serializable. La interfaz que no tiene ningún método para implementar, aunque lo estamos implementando para indicar algo al compilador o JVM (conocido como Marker Interface ). Entonces, si JVM ve que una clase es serializable, realiza alguna operación de procesamiento previo en esas clases. La operación es, agrega los siguientes dos métodos de muestra.
private void writeObject(java.io.ObjectOutputStream stream)
throws IOException {
stream.writeObject(name); // object property
stream.writeObject(address); // object property
}
private void readObject(java.io.ObjectInputStream stream)
throws IOException, ClassNotFoundException {
name = (String) stream.readObject(); // object property
address = (String) stream.readObject();// object property
}
¿Cuándo debería usarse en lugar de alguna otra técnica de persistencia?
La Serialization integrada es útil cuando el emisor y el receptor son ambos Java. Si desea evitar el tipo de problemas anterior, utilizamos XML o JSON con la ayuda de frameworks.
La principal ventaja de la serialización es que es extremadamente fácil de usar, relativamente rápido y conserva las mallas de objetos Java reales.
Pero debe tener en cuenta que en realidad no está destinado a ser utilizado para almacenar datos, sino principalmente como una forma de que diferentes instancias de JVM se comuniquen a través de una red utilizando el protocolo RMI.
La razón por la que almacenar una pequeña cantidad de información es que la forma en serie es relativamente grande es porque almacena información sobre las clases de los objetos que se serializan. Si almacena un duplicado de su lista, verá que el archivo no ha crecido demasiado. Almacene el mismo objeto dos veces y la diferencia es pequeña.
Los pros importantes son: relativamente fácil de usar, bastante rápido y puede evolucionar (como XML). Sin embargo, los datos son bastante opacos, es solo de Java, combina los datos con las clases y los datos que no son de confianza pueden causar DoS. Debería pensar en la forma serializada, en lugar de simplemente golpear los implements Serializable todas partes.
La ventaja de Java Object Serialization (JOS) es que simplemente funciona. También hay herramientas que hacen lo mismo que JOS, pero usan un formato XML en lugar de un formato binario.
Acerca de la longitud: JOS escribe cierta información de clase al inicio, en lugar de como parte de cada instancia; por ejemplo, los nombres completos de campo se graban una vez y se utiliza un índice en esa lista de nombres para las instancias de la clase. Esto hace que la salida sea más larga si solo escribe una instancia de la clase, pero es más eficiente si escribe varias instancias (diferentes) de ella. No me queda claro si su ejemplo realmente usa una clase, pero esta es la razón general por la cual JOS es más largo de lo que cabría esperar.
Por cierto: esto es incidental, pero no creo que JSON registre los nombres de las clases (como lo ha hecho en su ejemplo), por lo que podría no hacer lo que necesita.
Me encontré con este dilema hace un mes (ver la pregunta que hice ).
La principal lección que aprendí de ella es utilizar la serialización de Java solo cuando sea necesario y si no hay otra opción. Como dijo Jon, tiene sus fallas, mientras que otras técnicas de serialización son mucho más fáciles, más rápidas y más portátiles.
Serializar significa que coloca sus datos estructurados en sus clases en un orden plano de bytecode para guardarlo.
Por lo general, debe usar otras técnicas además del buildin java-method, está hecho para funcionar de la caja pero si tiene algunos cambios de contenido o cambios de pedidos en el futuro en sus clases serializadas, se mete en problemas porque no podrá cargarlos ellos correctamente
Si no tiene demasiados datos, puede guardar objetos en un objeto java.util.Properties. Un ejemplo de un par clave / valor sería user_1234_firstname = Peter. Usar la reflexión para guardar y cargar objetos puede facilitar las cosas.
Yo personalmente trataría de evitar la serialización "incorporada" de Java:
- No es portátil para otras plataformas
- No es muy eficiente
- Es frágil: hacer que lidie con múltiples versiones de una clase es algo complicado. Incluso los compiladores cambiantes pueden romper la serialización a menos que tenga cuidado.
Para obtener más información sobre el significado de los bytes reales, consulte la especificación de serialización de objetos Java .
Hay varias alternativas, tales como:
- XML y JSON, como has demostrado (varios sabores XML, por supuesto)
- YAML
- Thrift de Facebook (RPC y serialización)
- Buffers del Protocolo de Google
- Hessian (servicios web, así como serialización)
- Apache Avro
- Su propio formato personalizado
(Descargo de responsabilidad: trabajo para Google, y estoy haciendo un puerto de Protocol Buffers to C # como mi proyecto del 20%, así que creo que es una buena tecnología :)
Los formatos multiplataforma son casi siempre más restrictivos que los formatos específicos de la plataforma por razones obvias (los Protocolos de Protocolo tienen un conjunto bastante limitado de tipos nativos, por ejemplo), pero la interoperabilidad puede ser increíblemente útil. También debe tener en cuenta el impacto del control de versiones, con la compatibilidad hacia adelante y hacia atrás, etc. Los formatos de texto generalmente se pueden editar a mano, pero tienden a ser menos eficientes tanto en el espacio como en el tiempo.
Básicamente, debe observar sus requisitos cuidadosamente.
consulte el Protocolo de secuencia de serialización de objetos de Java para obtener una descripción del formato de archivo de una gramática utilizada para objetos serializados.
Personalmente, creo que la serialización incorporada es aceptable para persistir datos de corta vida (por ejemplo, almacenar el estado de un objeto de sesión entre solicitudes HTTP) que no es relevante fuera de su aplicación.
Para datos que tienen un tiempo de vida más largo o que deberían usarse fuera de su aplicación, persistiría ya sea en una base de datos o al menos usaría un formato más comúnmente usado ...