J'ai un problème dans mon codeBase où nous ne fermons pas correctement les poignées de fichiers, ni probablement des flux. Nous finissons éventuellement à obtenir une exception toomanyopenfiles sous une charge très lourde. Sur la base de la production de LSOF, nous sommes à peu près sûrs que nous savons où la fuite est (dans notre système de forage forestier), mais ma question est la suivante: comment puis-je écrire un test unitaire qui vérifie, lorsqu'il est complet, ces ressources ont été fermées correctement? Existe-t-il un moyen d'interroger le JRE pour savoir combien de fichiers sont actuellement ouverts? Puis-je intercepter des opérations de fichier pour que je puisse les surveiller?
Je soupçonne que je devrai instruminer mon code afin de gérer tous les fichiers d'E / S, de compter des références et de vous assurer qu'ils se ferment fermés de cette façon, mais si quelqu'un sait une solution descendante ressentie à ces idées. J'ai mentionné ci-dessus, ce serait une aide énorme!
4 Réponses :
Vous pouvez utiliser un outil de programmation orienté verso (AOP) comme AspectJ pour ajouter du code à compter ouvert / Fichiers fermés sur FileInputStream et FileOutPutStream . Ceci est assez facile à faire (des détails dépendent de l'outil, bien sûr) robustes et non invasifs.
Je pense que Aspectj n'est que non invasif lorsque vous envisagez de changer votre chaîne de construction non invasive.
Ceci est pour un bâtiment de test avec AspectJ ferait partie de la mise en place des tests.
Oui, cela semble être plus que je voudrais ajouter à ce code de bibliothèque de niveau assez bas.
On dirait que vous pouvez regarder ceci via jmx.
Quelqu'un a affiché le code ici: http://java-monitor.com/forum/showthread.php?t=130
Vous devez activer JMX dans votre JVM si vous ne l'avez pas déjà fait.
Cela ressemble à une bonne approche opérationnelle, mais je ne pense pas que cela fonctionnera comme un test unitaire.
Depuis que vous parlez de tests, PowerMock http://code.google.com/p/powermock / pourrait faire le tour. Il permet de se moquer de méthodes et de constructeurs statiques si je ne me trompe pas. Donc, vous pourriez vous moquer / espionner sur les constructeurs et sur les méthodes de fermeture ou ce dont vous avez besoin de libérer les ressources.
J'essaie de l'éviter dans mes tests, mais dans le cas où vous décrivez cela pourrait valoir le problème.
Je marquais cette réponse comme étant correcte, car il se rapproche de plus près de ce que je cherchais, mais dans mon cas, je n'ai choisi de ne pas écrire un test de l'unité à la fin. Il suffit d'utiliser LSOF pour vérifier que les fichiers n'étaient pas fermés avant mon patch et deviennent fermés après.
Vous pouvez écrire votre propre "bibliothèque" pour les classes IO normales, FileInputStream, etc. qui suit (en test) Quel appelant l'a ouvert, s'il est toujours ouvert, une liste mondiale, etc. FileInputStream. Ensuite, utilisez-le partout dans votre code au lieu d'une "normale" fichierInputStream et al.
Puis à la fin de votre test de votre appareil, vous affirmez Une autre option serait d'écrire vos méthodes afin qu'elles acceptent FileInputStream en tant que paramètre, puis appelez-les, puis affirmez que votre paramètre est sorti sur "Fermé maintenant" après la fin de la méthode.
ou si vous savez que vous serez sur Linux, effectuez un appel système à Pour une raison quelconque sur OS X, ce n'est pas si facile, il ne montre pas "(supprimé)" mais vous pouvez toujours détecter si le fichier est parti en boucle sur enveloppéfileInputtreams.Assertainwereclosed ou qu'avez-vous?
lsof et il ne doit pas énumérer aucun fichier comme emplacement '(supprimé)'. https://unix.stackexchange.com/a/64737/8337
lsof -p ... et vérifier si chaque fichier est en fait là sur le système de fichiers ...
Je crois que Java fait tout cela à l'arrière-plan, de sorte qu'il devrait être pris en charge. Hmm, peut-être que je manque cependant
Java éventuellement des ordures collecter et fermer vos fichiers ouverts, mais si vous ouvrez et jetez des ressources très rapidement, cela ne sera pas en mesure de suivre. Les poignées de fermeture explicitement sont beaucoup mieux.