A serialização é usada para persistência em Java. Pode ser bom persistir alguns objetos usando serialização. Mas, para um grande número de objetos, ORM, banco de dados etc. pode ser melhor. Parece que a serialização é útil apenas para pequenos trabalhos. Talvez eu esteja errado. Então, diga-me quais são as vantagens da serialização sobre os métodos de não serialização? Quando deve ser usado e quando deve ser evitado?
Esta pergunta veio à minha mente depois de ver o artigo da DZone A serialização de objetos é ruim ?
E estas são as linhas que deram origem à minha pergunta:
Se você observar o Java e seus objetos de sessão, será usada a serialização pura de objetos. Supondo que uma sessão de aplicativo tenha vida útil relativamente curta, ou seja, no máximo algumas horas, a serialização de objeto é simples, bem suportada e incorporada ao conceito Java de uma sessão. No entanto, quando a persistência dos dados ocorre por um longo período de tempo, possivelmente dias ou semanas, e você precisa se preocupar com novos lançamentos do aplicativo, a serialização rapidamente se torna ruim. Como qualquer bom desenvolvedor Java sabe, se você planeja serializar um objeto, mesmo em uma sessão, precisa de um ID de serialização real (serialVersionUID), não apenas de 1L, e precisa implementar a interface Serializable. No entanto, a maioria dos desenvolvedores não conhece as regras reais por trás do processo de desserialização do Java. Se o seu objeto foi alterado, mais do que adicionar campos simples ao objeto, é possível que Java não possa desserializar o objeto corretamente, mesmo que o ID de serialização não tenha sido alterado. De repente, você não pode mais recuperar seus dados, o que é inerentemente ruim.
Agora, os desenvolvedores que estão lendo isso podem dizer que nunca escreveriam código que tivesse esse problema. Isso pode ser verdade, mas e uma biblioteca que você usa ou algum outro desenvolvedor que não é mais empregado por sua empresa? Você pode garantir que esse problema nunca aconteça? A única maneira de garantir isso é usar um método de serialização diferente.
fonte
1L' não está correta.Respostas:
A serialização é usada principalmente em duas áreas:
prototipagem de persistência
praticamente todos os gráficos de objetos podem ser rapidamente serializados, para provas rápidas de conceitos ou aplicativos rápidos e sujos, isso pode ser mais rápido do que configurar uma camada ORM real ou outro sistema de persistência
armazenamento de curto prazo de objetos quase arbitrários:
Os servidores de aplicativos, por exemplo, tendem a persistir nas informações da sessão usando serialização. Isso tem a vantagem de que os valores na sessão podem ser de quase qualquer tipo (desde que seja serializável).
Para quase todos os outros usos, as desvantagens que você (e o artigo) mencionam são muito grandes: o formato exato é difícil de manter estável, as alterações de classe podem facilmente tornar seus dados serializados ilegíveis, ler / gravar os dados em código não Java é quase impossível (ou pelo menos muito mais difícil do que o necessário).
O JAXB e tecnologias semelhantes fornecem funções semelhantes com um custo igualmente baixo, enquanto reduzem alguns dos problemas.
fonte
Uso a serialização de objetos para permitir análises post-mortem em caso de erro inesperado na produção. As entradas para um cálculo são serializadas em um arquivo de dados. Se um erro for relatado, um programa simples pode recarregar as entradas e executar novamente o cálculo com um depurador conectado. Ou um shell groovy pode ser usado para recarregar os objetos e modificá-los, se desejado.
Também usamos serialização para passar objetos Java através de HTTP para um serviço da web. Muito mais fácil do que serializar para e do texto. A desvantagem é que as instalações do cliente e do servidor devem ser implantadas juntas, mas isso não é problema, pois controlamos as duas extremidades.
fonte
A serialização Java tem algumas vantagens:
Integrado ao sistema : você não precisa confiar em ferramentas, bibliotecas ou configurações de terceiros.
Relativamente simples de entender , pelo menos no começo.
Todo desenvolvedor sabe (ou deveria). Independentemente de os desenvolvedores Java aprovarem ou desaprovarem, é provável que estejam familiarizados com a serialização de objetos Java.
E, é claro, existem desvantagens:
Contorna o fluxo Java padrão. Aloca memória, mas não chama um construtor, portanto, os campos transitórios não são inicializados. Os campos são inicializados em ordem alfabética, não na ordem de origem.
Não é tão eficiente em termos de espaço, mas também não é horrível. Você pode compactar o resultado.
Frágil, a menos que você tome precauções quando seus objetos mudarem. E mesmo assim.
Use quando :
O tamanho da implantação é importante. Construído no sistema, portanto, 0 bytes extras.
Todos os atores usarão versões compatíveis.
O armazenamento a longo prazo não é um problema.
Evite quando :
fonte
Serialização e um ORM / banco de dados são coisas diferentes, embora haja alguma sobreposição.
Um objeto serializado representa todas as informações necessárias para "descongelar" um objeto persistente e repovoar seus dados. Um ORM e um banco de dados mantêm dados em um banco de dados. Uma classe pode ter campos de informações que não são armazenados no banco de dados pelo ORM, por exemplo, campo computado.
Além disso, a serialização e um ORM estão resolvendo problemas diferentes. A serialização resolve o problema de persistir um gráfico de objeto em um fluxo (memória, sistema de arquivos etc.). Um ORM lida com o mapeamento de informações para colunas de banco de dados e a recuperação e instanciação de objetos, além de fornecer detalhes como busca e carregamento lento.
Use um ORM quando desejar persistir dados em um banco de dados para situações em que você esteja lidando com grandes quantidades de dados ou precise de relatórios, pesquisas / consultas, armazenamento ou outras coisas em que os bancos de dados sejam bons. Use a serialização quando desejar salvar uma representação da (s) sua (s) estrutura (s) de dados no disco.
fonte
A serialização raramente é usada na prática.
Como já mencionado, o caso de uso mais comum para serialização é armazenar objetos como blobs em um banco de dados da sessão. Isso funciona bem por dois motivos: as sessões tendem a ter vida curta e o banco de dados da sessão, como nenhum conhecimento de como mapear objetos arbitrários para um modelo relacional.
Para dados que precisam ser retidos por longos períodos de tempo (como um carrinho de compras da Amazon), a melhor prática é armazenar esses dados em um banco de dados.
O mecanismo de persistência da sessão garante que um usuário com uma sessão ativa seja retornado ao mesmo servidor. O banco de dados da sessão é acessado apenas quando um servidor falha e o usuário é redirecionado para um novo servidor. O novo servidor detecta uma sessão ativa, mas não a encontra na memória, portanto, tenta recuperá-la do banco de dados da sessão, na tentativa de fornecer uma experiência perfeita ao usuário.
Há dois problemas com esta abordagem:
Primeiro, liberar os dados da sessão no banco de dados da sessão é um processo lento. A descarga de dados da sessão com muita frequência prejudica o desempenho, e a maioria dos servidores está configurada para liberar a cada 30 segundos, ou a cada minuto ou mais. Essa solução de failover "aparentemente" nunca é 100% eficaz.
Segundo, minha experiência é que a maioria dos clientes concorda em exibir uma mensagem de erro solicitando que o usuário efetue login e tente novamente durante os raros casos em que um servidor falha. Nesse caso, desligamos completamente o banco de dados da sessão e aproveitamos o aumento de desempenho.
Outro uso da serialização é fornecer tempos de resposta mais rápidos usando estruturas como o Flex, que usam serialização e compactação de gráficos de objetos para interações servidor-cliente.
Como outros já apontaram, existem algumas razões criativas e úteis para empregar a serialização, mas essas são raras na prática.
Historicamente, a serialização é difícil de implementar corretamente e a confiabilidade, restringindo seu uso a um pequeno número de casos. A maioria dos desenvolvedores nunca serializa objetos, mas pode contar com estruturas que o fazem nos bastidores.
fonte
Resposta curta para "quando usar a serialização Java" e "quando evitar a serialização Java"
Use serialização Java se
Em todas as outras situações, a "serialização binária Java" é ruim
Alternativas
fonte