Java sérialisation - avantages et inconvénients, utiliser ou éviter?
La sérialisation est utilisée pour la persistance en Java. Il peut être correct de conserver quelques objets en utilisant la sérialisation. Mais, pour un grand nombre d'objets, ORM, Database etc pourrait être mieux. Il semble que la sérialisation ne soit utile que pour les petits travaux. Peut-être que je me trompe. Alors, dites-moi quels sont les avantages de la sérialisation par rapport aux méthodes sans sérialisation? Quand faut-il l'utiliser et quand faut-il l'éviter?
Cette question m'est venue à l'esprit après avoir vu l'article de DZone Object Serialization Evil?
Et ce sont les lignes qui ont donné lieu à ma question:
Si vous regardez Java et ses objets de session, la sérialisation d'objets pure est utilisée. En supposant qu'une session d'application soit assez courte, ce qui signifie au plus quelques heures, la sérialisation d'objets est simple, bien prise en charge et intégré dans le Java concept d'une session. Cependant, lorsque la persistance des données est sur une plus longue période, peut-être des jours ou des semaines, et que vous devez vous soucier des nouvelles versions de l'application, la sérialisation devient rapidement mauvaise. Comme tout bon développeur Java le sait, si vous envisagez de sérialiser un objet, même dans une session, vous avez besoin d'un véritable ID de sérialisation (serialVersionUID), pas seulement d'un 1L, et vous devez implémenter l'interface Serializable. Cependant, la plupart des développeurs ne connaissent pas les vraies règles derrière le processus de désérialisation Java. Si votre objet a changé, plus que l'ajout de simples champs à l'objet, il il est possible que Java ne puisse pas désérialiser correctement l'objet même si l'ID de sérialisation n'a pas changé. Du coup, vous ne pouvez plus récupérer vos données, ce qui est intrinsèquement mauvais.
Maintenant, les développeurs qui lisent ceci peuvent dire qu'ils n'écriront jamais de code qui aurait ce problème. C'est peut-être vrai, mais qu'en est-il d'une bibliothèque que vous utilisez ou d'un autre développeur qui n'est plus employé par votre entreprise? Pouvez-vous garantir que ce problème ne se produira jamais? La seule façon de garantir cela est d'utiliser une méthode de sérialisation différente.
La sérialisation est principalement utilisée dans deux domaines:
prototypage de la persistance
à peu près tous les graphiques d'objets peuvent être rapidement sérialisés, pour des preuves de concepts rapides ou des applications rapides et sales, cela pourrait être plus rapide que de configurer une vraie couche ORM ou un autre système de persistance
stockage à court terme d'objets presque arbitraires:
Les serveurs d'applications, par exemple, ont tendance à conserver les informations de session à l'aide de la sérialisation. Cela a l'avantage que les valeurs de la session peuvent être de presque n'importe quel type (tant qu'elles sont sérialisables).
Pour presque toutes les autres utilisations, les inconvénients que vous (et l'article) mentionnez sont trop importants: le format exact est difficile à maintenir stable, les changements de classe peuvent facilement rendre vos données sérialisées illisibles, la lecture/écriture des données en code non Java est presque impossible (ou au moins beaucoup plus difficile que nécessaire).
JAXB et des technologies similaires offrent des fonctions similaires à un coût similaire, tout en réduisant certains des problèmes.
J'utilise la sérialisation d'objets pour permettre une analyse post-mortem en cas d'erreur de production inattendue. Les entrées d'un calcul sont sérialisées dans un fichier de données. Si une erreur est signalée, un programme simple peut recharger les entrées et réexécuter le calcul avec un débogueur attaché. Ou un Shell groovy peut être utilisé pour recharger les objets et les modifier si vous le souhaitez.
Nous utilisons également la sérialisation pour transmettre Java objets via HTTP à un service Web. Beaucoup plus facile que la sérialisation vers et depuis le texte. L'inconvénient est que les installations client et serveur doivent être déployées ensemble, mais ce n'est pas problème puisque nous contrôlons les deux extrémités.
Quels sont les avantages de la sérialisation par rapport aux méthodes sans sérialisation?
La sérialisation Java présente certains avantages:
Intégré au système: Vous n'avez pas besoin de compter sur des outils tiers, des bibliothèques ou une configuration.
Relativement simple à comprendre, au moins au début.
Chaque développeur le sait (ou devrait). Que les développeurs Java approuvent ou refusent), ils sont probablement familiarisés avec la sérialisation des objets Java.
Et, bien sûr, il y a des inconvénients:
Circonvents standard Java flow. Alloue de la mémoire mais n'appelle pas de constructeur, donc les champs transitoires ne sont pas initialisés. Les champs sont initialisés dans l'ordre alphabétique, pas dans l'ordre source.
Pas si efficace en termes d'espace, mais pas horrible non plus. Vous voudrez peut-être compresser le résultat.
fragile sauf si vous prenez des précautions lorsque vos objets changent. Et même alors.
Quand faut-il l'utiliser et quand faut-il l'éviter?
tilisez quand:
La taille du déploiement est importante. Intégré au système, donc 0 octet supplémentaire.
Tous les acteurs utiliseront des versions compatibles.
Le stockage à long terme n'est pas un problème.
à éviter quand:
- Aucune des conditions ci-dessus ne s'applique.
La sérialisation et une base de données ORM sont différentes, bien qu'il y ait un certain chevauchement.
Un objet sérialisé représente toutes les informations nécessaires pour "décongeler" un objet persistant et repeupler ses données. Un ORM et une base de données conservent les données dans une base de données. Une classe peut avoir des champs d'informations qui ne sont pas stockés dans la base de données par l'ORM, par exemple un champ calculé.
De plus, la sérialisation et un ORM résolvent différents problèmes. La sérialisation résout le problème de la persistance d'un graphe d'objet dans un flux (mémoire, système de fichiers, etc.). Un ORM gère le mappage des informations aux colonnes de la base de données et la récupération et l'instanciation des objets, en plus de fournir des subtilités telles que la recherche et le chargement paresseux.
Utilisez un ORM lorsque vous souhaitez conserver des données dans une base de données pour les situations où vous traitez de grandes quantités de données ou avez besoin de rapports, de recherches/requêtes, d'entreposage ou d'autres choses dans lesquelles les bases de données sont bonnes. Utilisez la sérialisation lorsque vous souhaitez enregistrer une représentation de vos structures de données sur le disque.
Réponse courte à "quand utiliser Java sérialisation" et "quand éviter Java sérialisation")
Utilisez Java sérialisation si
- peu de codage devrait être nécessaire
- peu importe que les données binaires ne soient pas lisibles par l'homme
- la recherche dans les données sérialisées n'est pas nécessaire (une requête de type base de données n'est pas possible)
- soit
- la structure des données sérialisées ne change pas ou
- peu importe si les données sérialisées stockées ne sont plus lisibles après un "changement de structure de données" (c'est-à-dire les données de session dans une application Web)
Dans toutes les autres situations, "Binary Java serialization" est mauvais
Alternatives
- sérialisation XML
- base de données nosql
- base de données relationnelle avec ORM
La sérialisation est rarement utilisée dans la pratique.
Comme déjà mentionné, le cas d'utilisation le plus courant pour la sérialisation est de stocker des objets en tant qu'objets blob dans une base de données de session. Cela fonctionne bien pour deux raisons: les sessions ont tendance à être de courte durée et la base de données des sessions ne sait pas comment mapper des objets arbitraires à un modèle relationnel.
Pour les données qui doivent être conservées pendant de longues périodes (comme un panier Amazon), la meilleure pratique consiste à stocker ces données dans une base de données.
Le mécanisme de persistance de session garantit qu'un utilisateur avec une session active est renvoyé vers le même serveur. La base de données de session n'est accessible qu'en cas de défaillance d'un serveur et que l'utilisateur est redirigé vers un nouveau serveur. Le nouveau serveur détecte une session active, mais ne la trouve pas en mémoire, il essaie donc de la récupérer dans la base de données de session afin de fournir une expérience transparente à l'utilisateur.
Il y a deux problèmes avec cette approche:
Tout d'abord, le vidage des données de session dans la base de données de session est un processus lent. Le vidage des données de session dégrade trop souvent les performances, et la plupart des serveurs sont configurés pour vider toutes les 30 secondes, ou toutes les minutes, ou plus. Cette solution de basculement "sans apparence" n'est jamais efficace à 100%.
Deuxièmement, mon expérience est que la plupart des clients conviennent que le lancement d'un message d'erreur demandant à l'utilisateur de se connecter et de réessayer dans les rares cas où un serveur tombe en panne. Dans ce cas, nous désactivons complètement la base de données de session et profitons de l'amélioration des performances.
Une autre utilisation de la sérialisation est de fournir des temps de réponse plus rapides en utilisant des frameworks comme Flex qui utilisent la sérialisation et la compression des graphiques d'objets pour les interactions serveur-client.
Comme d'autres l'ont souligné, il existe des raisons créatives et utiles d'employer la sérialisation, mais elles sont rares dans la pratique.
Historiquement, la sérialisation est difficile à mettre en œuvre correctement et sa fiabilité, limitant son utilisation à un petit nombre de cas. La plupart des développeurs ne sérialiseront jamais eux-mêmes les objets, mais peuvent s'appuyer sur des frameworks qui le font en arrière-plan.