Peut-il y avoir une fuite de mémoire en Java

Eh bien, étant donné que java utilise un garbage collector pour collecter les objets inutilisés, vous ne pouvez pas avoir de pointeur suspendu. Cependant, vous pouvez garder un objet dans la portée plus longtemps qu'il ne doit l'être, ce qui pourrait être considéré comme une fuite de mémoire. Plus à ce sujet ici: http://web.archive.org/web/20120722095536/http://www.ibm.com:80/developerworks/rational/library/05/0816_GuptaPalanki/

Tu fais un test sur ça ou quelque chose? Parce que c'est au moins un A+ juste là.

Oui. Les fuites de mémoire peuvent toujours se produire même lorsque vous avez un GC. Par exemple, vous pouvez conserver des ressources telles que des jeux de résultats de base de données que vous devez fermer manuellement.

La réponse est un ouiretentissant, mais c'est généralement le résultat du modèle de programmation plutôt qu'une indication d'un défaut dans la JVM. Ceci est courant lorsque les frameworks ont des cycles de vie différents de ceux d'une JVM en cours d'exécution. Voici quelques exemples:

1. le Rechargement d'un contexte
2. Omission de déréférencer les observateurs (auditeurs)
3. Oublier de nettoyer les ressources après avoir fini de les utiliser *

* - Des milliards de dollars de consultation ont été faits pour résoudre le dernier

Oui, dans le sens où votre application Java peut accumuler de la mémoire au fil du temps que le garbage collector est incapable de libérer.

En conservant les références aux objets non hérités/indésirables, ils ne tomberont jamais hors de portée et leur mémoire ne sera pas récupérée.

Oui, si vous ne dé-référencez pas les objets, ils ne seront jamais collectés et l'utilisation de la mémoire augmentera. cependant, en raison de la façon dont java est conçu, cela est difficile à réaliser alors que dans d'autres langages, il est parfois difficile de ne pas le faire.

Edit: lire le lien d'Amokrane. que c'est bon.

Oui c'est possible.

En Java effectif, il existe un exemple impliquant une pile implémentée à l'aide de tableaux. Si vos opérations pop décrémentent simplement la valeur d'index, il est possible d'avoir une fuite de mémoire. Pourquoi? Parce que votre tableau a toujours une référence à la valeur apparue et que vous avez toujours une référence à l'objet stack. La bonne chose à faire pour cette implémentation de pile serait donc d'effacer la référence à la valeur sauté à l'aide d'une affectation nulle explicite au tableau sauté index.

La réponse courte:

Une JVM compétente n'a pas de mémoire fuites, mais plus de mémoire peut être utilisée ce qui est nécessaire, parce que pas tous inutilisés les objets ont été ramassés, encore. En outre, les applications Java elles-mêmes peuvent contenir des références à des objets dont elles n'ont plus besoin, ce qui peut entraîner une fuite de mémoire.

Une réponse encore plus courte:

Java est un langage et ne peut pas avoir fuites de mémoire, seulement Java Virtuel Les machines peuvent.

Le livre Effective Java donne deux autres raisons de "fuites de mémoire":

• Une fois que vous mettez la référence d'objet dans Cache et oubliez qu'elle est là. La référence reste dans le cache longtemps avant de devenir non pertinente. La solution consiste à représenter le cache comme un WeakHashMap
• dans une API où les clients enregistrent des rappels et ne les réenregistrent pas explicitement. La solution est de ne stocker que des références faibles à eux.

Une réponse simple est : JVM prendra soin de toute votre initialisation des [vieux objets java simples] de POJO tant que vous ne travaillez pas avec JNI. Avec JNI si vous avez fait une allocation de mémoire avec le code natif, vous devez prendre soin de cette mémoire par vous-même.

Oui. Une fuite de mémoire est la mémoire inutilisée pas publié pour le gestionnaire de mémoire par l'application.

J'ai vu plusieurs fois du code Java qui stocke des éléments sur une structure de données mais les éléments ne sont jamais supprimés de là, remplissant la mémoire jusqu'à une OutOfMemoryError:

void f() {
    List<Integer> w = new ArrayList<Integer>();
    while (true) {
         w.add(new Integer(42));
    }
}

Bien que cet exemple soit trop évident, les erreurs de mémoire Java ont tendance à être plus subtiles. Par exemple, en utilisant l'injection de dépendance, vous stockez un objet énorme sur un composant avec SESSION scope , sans le libérer lorsque l'objet n'est plus utilisé.

Sur une machine virtuelle 64 bits, cela a tendance à s'aggraver car l'espace mémoire d'échange commence à être rempli jusqu'à ce que le système explore trop d'opérations d'E / S.

Oui, cela peut être, dans un contexte où un programme détient par erreur une référence à un objet qui ne serait plus jamais utilisé et donc il n'est pas nettoyé par le GC.

Un exemple à cela, serait oublier de fermer un flux ouvert:

class MemoryLeak {

    private void startLeaking() throws IOException {
        StringBuilder input = new StringBuilder();
        URLConnection conn = new URL("www.example.com/file.txt").openConnection();

        BufferedReader br = new BufferedReader(new InputStreamReader(conn.getInputStream(), StandardCharsets.UTF_8));        

        while (br.readLine() != null) {
            input.append(br.readLine());
        }
    }

    public static void main(String[] args) throws IOException {
        MemoryLeak ml = new MemoryLeak();
        ml.startLeaking();
    }
}