Je n'ai pas d'exemple de code, mais je suis curieux de savoir s'il est possible d'écrire du code Python qui entraîne essentiellement une fuite de mémoire.Est-il possible d'avoir une fuite de mémoire réelle en Python à cause de votre code?
C'est possible, oui.
Cela dépend du type de fuite de mémoire dont vous parlez. Dans le code python pur, il n'est pas possible d'oublier de libérer de la mémoire, comme en C, mais il est possible de laisser une référence suspendue quelque part. Quelques exemples de tels:
un objet retraçage unhandled qui maintient une trame entière de la pile en vie, même si la fonction est plus en cours d'exécution
stocker des valeurs dans un champ de classe ou globale au lieu de la portée de l'instance , et ne pas le réaliser.
Références cycliques dans les classes qui ont également une méthode __del__. Ironiquement, l'existence d'un __del__ rend impossible pour le garbage collector cyclique de nettoyer une instance.
extensions C mal implémentées ou n'utilisant pas correctement les bibliothèques C comme elles sont supposées l'être.
Scopes qui contiennent des fermetures qui contiennent beaucoup plus que vous auriez pu prévoir
paramètres par défaut qui sont des types mutables:
.
def foo(a=[]):
a.append(time.time())
return a
Et beaucoup plus .....
Belle mention des paramètres par défaut mutables. Ils sont dangereux parce que leur façon de travailler n'est pas vraiment intuitive, mais aussi parce qu'ils peuvent grandir beaucoup si vous ne vous en occupez pas ... +1 –
+1 pour avoir mentionné cette implémentation de la méthode foo. Je n'ai jamais su cela! –
Pourriez-vous élaborer ou fournir de la documentation sur votre première puce "un objet de traceback non géré qui conserve un cadre de pile entier en vie, même si la fonction n'est plus en cours d'exécution"? J'ai réellement une fuite de retraçage mais je ne vois pas pourquoi il est référencé n'importe où (https://stackoverflow.com/questions/44681681/what-could-prevent-a-traceback-from-being-garbage-collected) – BiAiB
Bien sûr, vous pouvez. L'exemple typique d'une fuite de mémoire est si vous construisez un cache que vous ne videz jamais manuellement et qui n'a pas de politique d'expulsion automatique.
Techniquement, ce n'est pas une fuite de mémoire car l'application est toujours capable ** ** de libérer la mémoire, même si elle choisit de ne pas le faire. – Justin
Eh bien, je pense juste que nous définissons différemment "fuite de mémoire". Pour moi, une fuite est une fuite, qu'il soit possible ou non de la réparer. –
S'il n'a pas de code pour supprimer des éléments du cache, il n'est pas en mesure de les supprimer, n'est-ce pas? –
Dans le sens de l'orphelinat des objets alloués après leur sortie de la portée parce que vous avez oublié de les libérer, non; Python libère automatiquement les objets hors de portée (Garbage Collection). Mais dans le sens où @Antione parle, oui.
La définition classique d'une fuite de mémoire est une mémoire qui a été utilisée qu'une seule fois, et est maintenant pas, mais n'a pas été remis en état. C'est presque impossible avec du code pur Python. Mais comme le souligne Antoine, vous pouvez facilement consommer toute votre mémoire par inadvertance en permettant aux structures de données de se développer sans limite, même si vous n'avez pas besoin de conserver toutes les données.
Avec les extensions C, bien sûr, vous êtes de retour en territoire non géré, et tout est possible.
Vous devriez clarifier: parlez-vous de la fuite de mémoire après l'exécution du processus; et parlez-vous de Python pur sans modules C? –