Lors du chargement de tous les tests de l'unité dans un package, la tâche de fabrication jette une erreur Java.lang.outofMemororyError: Erreur d'espace Heap Java.
Si j'exécute tous les tests de chaque sous-vue, tous les tests se chargent et complètent tout simplement bien. Ce n'est que lorsque j'essaie d'exécuter tous les tests du paquet parent que l'erreur OOM survient.
Je ne pense pas que ce problème soit résolu en modifiant les paramètres VM. J'ai essayé d'augmenter la taille maximale du tas et de la Perm, et cela n'a pas résolu le problème.
Cela me conduit à croire qu'il existe des ordures à problèmes de récupération entre les tests de chargement de différents forfaits, ou qu'il existe un chargement trop désireux de classe.
Y a-t-il un paramètre Junit qui pourrait s'occuper de ces problèmes ou le problème va-t-il être résolu en modifiant ou en ajoutant du code dans les cas de test?
4 Réponses :
Le GC est exécuté lorsque la CPU dispose d'un temps libre ou de la mémoire libre est faible. Si vos tests crash, vous pourriez avoir une fuite de mémoire quelque part. (Oui, ils existent aussi en Java)
Recherchez des références circulaires et des classes statiques / variables.thèses sont des raisons communes de la mémoire des fuites de mémoire. Vous devriez également consulter JConsole.
Vous devez définir tous les champs des classes de test sur La raison est que Junit instancitait une instance de la classe de test par test . Il conserve cette instance pour tout le temps pour enregistrer les résultats du test (succès, échec, trace de pile). Donc, si vous utilisez des champs, ils resteront et vous manquerez de mémoire. NULL dans dératrement () .
Cool, je vais tester ce correctif en premier.
Malheureusement, cela n'a pas résolu le problème. Ne déchirez-vous pas uniquement () uniquement appelé que toutes les classes ont été chargées et les tests commencent à courir? L'erreur OOM que je vois se produit pendant la tâche de fabrication, avant que les tests ne commencent même à courir.
Non, la dérappement est appelée après chaque test individuel. Mais j'ai manqué "dans la tâche de fabrication". De quelle tâche parlez-vous? Utilisez-vous une fourmi? Ou gnu faire?
D'accord. Est-ce que Ant va même commencer à démarrer les tests de l'unité? Courez-le avec -d pour voir où il échoue vraiment.
J'ai connu un problème similaire à l'aide de Testng et l'a attribué à la quantité d'informations de journal que je produisais sur la console. Une fois que j'avais réduit cela, j'ai pu exécuter ma suite de test sans problèmes de mémoire.
Observé ce même problème à exécuter des tests avec JUnit et Maven. Le niveau de journalisation était au débogage et créant des erreurs OOM, après avoir commuté une erreur, les problèmes sont partis.
Pour moi, définir NULL TestClass ne résoue pas. CoZ Chaque test prend la mémoire sur Eclipse VM afin que la meilleure chose à faire (résoudre pour moi) tue le contexte d'application Junit (en utilisant @dirtiescontext ) pour chaque classe de test terminée! Comme ci-dessous
Êtes-vous sûr de ne pas avoir de consommation de mémoire importante dans la statique de vos cours de test ou dans les statiques de vos cours de test?
Comment avez-vous réellement modifié les paramètres VM? Essayez de confirmer qu'ils ont été définis correctement par les méthodes de Java.Lang.Runtime
Je ne suis pas sûr de la consommation de mémoire de la statique, mais je vais certainement examiner. Quant aux paramètres VM, j'ai essayé ceci: -xmx512m -xx: permsize = 128m -xx: maxpermsize = 512m mais les augmenter ne les aident pas à résoudre l'erreur OOM.