1
votes

Amélioration de l'impression des détails dans log4j

J'ai le code suivant. Le niveau de journalisation est INFO . Comment pouvons-nous écrire le meilleur code pour que la toString ne soit pas exécutée?

Set<Integer> resultUserIdsSet = new HashSet<>();
log.trace("userIdsSet={}", resultUserIdsSet.toString());

Remarque: Le resultUserIdsSet contient des millions d'entiers.

Nous utilisons ch.qos.logback: logback-classic: jar: 1.2.3


0 commentaires

3 Réponses :


0
votes

Chargement paresseux par fournisseur:

Set<Integer> resultUserIdsSet = new HashSet<>();
log.trace(() -> "userIdsSet=" + resultUserIdsSet);


1 commentaires

Nous utilisons ch.qos.logback: logback-classic: jar: 1.2.3. et la surcharge avec le fournisseur n'existe pas. Dans quel journal et dans quelle version le fournisseur existe-t-il?



1
votes

Qu'est-ce que "log"? Maintenant, toutes les implémentations permettent de passer le fournisseur comme cela a été mentionné dans d'autres réponses. Il existe un RFE fixe pour cela dans SLF4J, mais veuillez préciser ce qu'est exactement le bibliothèque dont vous parlez, quelle est la version, etc.

Pour les anciennes versions, il est toujours possible d'utiliser l'ancienne construction comme celle-ci:

if(log.isTraceEnabled()) {
    log.trace("userIdsSet={}", resultUserIdsSet.toString());
}

Maintenant, peu importe le support du Fournisseur qui peut vraiment résoudre le problème, je voudrais porter votre attention sur la note:

Remarque: le resultUserIdsSet contient des millions d'entiers.

C'est assez problématique: Si vous placez une instruction de journalisation comme celle-ci, vous voulez vraiment qu'elle soit imprimée au niveau de trace. Lorsque le suivi est désactivé (lu presque toujours), vous pouvez éviter de faire un calcul "toString" coûteux comme cela a été mentionné dans les réponses. Cependant, alors nous activons la trace et cela créera un million d'entiers dans l'ensemble, de nombreuses choses "intéressantes" peuvent se produire:

  • Des millions d'entiers sont très coûteux à imprimer par les ajouteurs, à la fois pour la console et pour l'archivage, car il y a vraiment trop de données et les opérations d'E / S coûtent cher.
  • Même si vous imprimez des millions d'entiers, il sera vraiment difficile de comprendre quelque chose à partir de ce journal.
  • Les choses vont s'aggraver si vous imprimez ceci dans une sorte de boucle for externe

En fin de compte, réfléchissez à deux fois si vous voulez vraiment imprimer tous ces identifiants. Peut-être qu'il est judicieux de tronquer la sortie + fournir des statistiques à usage général comme le nombre d'identifiants dans l'ensemble, etc.


3 commentaires

Nous utilisons ch.qos.logback: logback-classic: jar: 1.2.3


Je ne vois pas qu'il prend en charge les lambdas en général, donc probablement si (log.isTraceEnabled ()) est la voie à suivre.


Dans quelle implémentation et version de journal le paramètre Supplier existe-t-il?



3
votes

Tout le monde vous dit d'utiliser un fournisseur, mais ce n'est pas nécessaire. Laissez simplement le logger faire l'appel toString:

log.trace("userIdsSet={}", resultUserIdsSet);

En supprimant .toString () , vous passez simplement une référence à l'ensemble. Si le niveau de trace n'est pas activé, l'appel du journal est renvoyé immédiatement; le coût est essentiellement négligeable.

Si et seulement si le niveau de trace est activé, alors le logger appellera toString () sur l'ensemble.


0 commentaires