Est-il nécessaire de se déconnecter de la base de données une fois le travail effectué en Java? S'il n'est pas déconnecté, cela entraînera-t-il des fuites de mémoire?Dois-je me déconnecter explicitement d'une base de données lors de l'utilisation de Java?
Vous devez fournir plus de détails, comme le framework que vous utilisez ou quelque chose.
De toute façon, utilisez-vous JDBC? Si c'est le cas, vous devez fermer les objets suivants en utilisant leurs méthodes close() respectives: Statement, ResultSet et Connection.
Vous devez toujours fermer toutes vos connexions, déclarations et ensembles de résultats. Si ce n'est pas le cas, il est plus probable que vous ne puissiez pas obtenir de nouvelles connexions du pool qu'une fuite de mémoire.
Je n'ai pas de source, mais je crois (si je me souviens bien, cela fait longtemps que je n'ai pas touché JDBC) que cela dépend de l'implémentation du pilote JDBC. Vous devriez toujours fermer vos connexions et nettoyer après vous car tous les pilotes JDBC ne le font pas pour vous (bien que certains pourraient le faire).
Cela revient à une règle que j'aime suivre - Si je crée ou ouvre quelque chose, je suis responsable de la supprimer ou de le fermer.
En supposant que vous utilisez JDBC, la réponse est oui. Si vous ne fermez pas la connexion, le pilote JDBC peut essayer de la fermer dans un finalliseur, mais cela peut bloquer la connexion pendant une période très longue, entraînant des problèmes de ressources (la quantité de connexions à la base de données peut être ouverte à un le temps est fini). Typiquement, la programmation JDBC est faite avec un pool de base de données, et ne pas fermer la connexion signifie que le pool manquera de connexions disponibles très rapidement.
Certains serveurs d'applications (par exemple, JBoss) détectent lorsqu'une connexion n'est pas fermée et la ferment pour vous si elle gère les transactions, mais vous ne devez pas vous fier à cela.
Bien sûr, certains pilotes JDBC ne sont pas de purs pilotes Java, à quel point les fuites de mémoire deviennent une possibilité très réelle.
oui et oui