Devrait être logger private static ou non

Question

Devrait être logger déclaré statique ou pas? D'habitude j'ai vu deux types de déclaration pour un logger :

 protégé Log Log = new Log4JLogger(aClass.class);

ou

 private static Log Log = new Log4JLogger(aClass.class);

Lequel doit être utilisé? quels sont les avantages et les inconvénients des deux?

Je vous remercie.

Answer 1

L'avantage de la non-forme statique, c'est que vous pouvez les déclarer dans un (résumé) de la classe de base comme suit, sans se soucier que le droit classname:

protected Log log = new Log4JLogger(getClass());

Cependant, son inconvénient est bien sûr qu'un tout nouveau journal instance sera créée pour chaque instance de la classe. Cela ne peut pas en soi être coûteux, mais il ajoute une surcharge importante. Si vous voulez éviter cela, vous souhaitez utiliser l' static formulaire. Mais son inconvénient est que vous devez le déclarer dans chaque classe individuelle et de prendre soin, dans chaque classe, que le droit classname été utilisés au cours de l'enregistreur de la construction parce qu' getClass() ne peut pas être utilisé dans le contexte statique. Cependant, dans la moyenne des IDE, vous pouvez créer une saisie semi-automatique modèle pour cela. E. g. logger + ctrl+space.

D'autre part, si vous obtenez l'enregistreur par une usine qui, à son tour, peut mettre en cache le déjà instancié bûcherons, puis à l'aide de la non-forme statique ne sera pas ajouter beaucoup de frais généraux. Log4j, par exemple, a un LogManager pour ce but.

protected Log log = LogManager.getLogger(getClass());

Answer 2

J'ai l'habitude de penser que tous les enregistreurs doivent être statique; toutefois, le présent article à wiki.apache.org apporte quelques importants problèmes de mémoire, à propos du chargeur de classe de fuites. Déclaration d'un journal comme statique empêche de déclarer la classe (ainsi que les chargeurs de classes) à partir de déchets collectés dans un conteneur J2EE que l'utilisation partagée du chargeur de classe. Il en résultera PermGen des erreurs si vous redéployer votre demande assez de temps.

Je ne vois vraiment pas une façon de travailler autour de cette classloader problème de fuite, d'autres que de déclarer des enregistreurs de non-statique.

Answer 3

La différence la plus importante est de savoir comment il affecte votre fichiers journaux: dans quelle catégorie les journaux d'aller?

• Dans votre premier choix, les journaux d'une sous-classe de fin dans la catégorie de la super-classe. Qui me semble être très contre-intuitif pour moi.

• Il y a une variante de votre premier cas:

  protégé Log Log = new Log4JLogger(getClass());

  Dans ce cas, votre catégorie de journal dit que l'objet sur lequel le code qui a enregistré a été de travailler sur.

• Dans votre deuxième choix (private static), le journal de la catégorie est la classe qui contient le code d'enregistrement. Donc, normalement, la classe qui est en train de faire la chose qui est enregistré.

Je recommande fortement cette dernière option. Il a ces avantages, par rapport aux autres solutions:

• Il existe une relation directe entre le journal et le code. Il est facile à trouver en arrière, là où un message de log est venu.
• Si quelqu'un a à tune des niveaux d'enregistrement (ce qui est fait par catégorie), c'est généralement parce qu'ils sont intéressés (ou pas) dans certains des messages particuliers, écrit par une classe particulière. Si la catégorie n'est pas la classe qui est écrit les messages, il est plus difficile de régler le niveau.
• Vous pouvez vous connecter à des méthodes statiques
• Les bûcherons ont seulement besoin d'être initialisé (ou regardé plus d'une fois par classe, donc au démarrage, au lieu de pour chaque instance créée.

Il a également des inconvénients:

• Il doit être déclaré dans chaque classe où vous vous connectez messages (pas de réutilisation de la super-classe enregistreurs).
• Vous avez besoin de prendre soin de mettre le droit classname lors de l'initialisation de l'enregistreur. (Mais bon IDE de prendre soin de cela pour vous).

Answer 4

Utilisation de l'inversion de contrôle et de passer l'enregistreur dans le constructeur. Si vous créez l'enregistreur de données à l'intérieur de la classe, vous allez avoir un diable de temps avec vos tests unitaires. Vous l'écriture de tests unitaires ne sont pas vous?

Answer 5

Je m'en tiendrais avec le secteur privé, et statique, pour sûr. Si vous opter pour une protection, le même enregistreur de données est utilisé pour tous vos sous-classes, trop (ou le parent de l'enregistreur caché par un enfant de l'enregistreur du même nom). Avec le secteur privé, vous obtenez un enregistreur différente pour chaque classe, et qui vous donne une granularité plus fine pour l'activation de la journalisation. C'est une bonne chose.