Jaki jest narzut tworzenia rejestratorów SLF4J w kontekście statycznym i nie statycznym?

Question

Zawsze stosować następujący wzór do skonstruowania (slf4j) rejestratory:

private static final Logger log = LoggerFactory.getLogger(MyClass.class); 

ten pracował tak daleko, ale zastanawiałem się o kontekście static w pewnym momencie i konieczności przejścia w konkretnej klasie dosłowne cały czas, a nie tylko przy użyciu non-statyczne rejestratora jak

private final Logger log = LoggerFactory.getLogger(getClass()); 

To w zasadzie został poproszony (a odpowiedział), zanim tutaj LOG4J

Should logger be private static or not

i tutaj

Should be logger always final and static?

Zdaję sobie sprawę final jest w zasadzie obowiązkowe, więc jestem zastanawiać, jak wysoko nad głową z użyciem slf4j w kontekście non-statycznej rzeczywistości.

Q:

Czy istnieje znacząca praktyczna narzut użyciu

private final Logger log = LoggerFactory.getLogger(getClass()); 

nad

private static final Logger log = LoggerFactory.getLogger(MyClass.class); 

średniej (web) aplikacji ? (Nie ma potrzeby, aby „omówić” high-end, ciężkie obciążenia webapps tutaj)

---

Uwaga, ja ostatecznie planuje użyć nawet ładniejszy podejścia z wykorzystaniem CDI aby uzyskać rejestrator slf4j jak

@Inject private final Logger log; 

jak opisano tutaj http://www.seamframework.org/Weld/PortableExtensionsPackage#H-TtLoggerttInjection, ale najpierw muszę wiedzieć o buforowaniu rejestratora.

Sub pytanie: czy jest to w ogóle możliwe, aby używać ?:

@Inject private static final Logger log; 

(dopiero zaczynają z CDI, aby być uczciwym)

Answer 1

Napełnienie dla zmiennych rejestratora niestatycznego (instancji) powinno być pomijalne, chyba że wystąpi wiele, powiedzmy 10000 lub więcej wystąpień. Kluczowe słowo tutaj jest znikome. Jeśli zostanie utworzonych wiele (> 10000) obiektów, wpływ będzie prawdopodobnie możliwy do zmierzenia, ale nadal będzie niski.

Mówiąc dokładniej, rejestrator instancji zwiększa obszar pamięci o jeden punkt odniesienia (64 bity) na instancję obiektu. Po stronie procesora koszt jest jednym haszowaniem według instancji, tj. Kosztem wyszukania odpowiedniego rejestratora w tabeli mieszania (małe). Ponownie, oba koszty powinny być pomijalne, chyba że powstanie wiele obiektów.

To pytanie jest również omawiane w artykule SLF4J FAQ.

Answer 2

nie jestem pewien co do dokładnej napowietrznych przy użyciu LoggerFactory ale wątpię wpłynie na wydajność twojej aplikacji. Po prostu użyj statycznego lub nie statycznego, jak uważasz za stosowne.

Co powinno być zaletą korzystania z @Inject. The LoggerFactory już zapewnia i abstrahuje od konkretnej impl. W każdym razie będzie o wiele wolniej niż LoggerFactory.

Składnia jest bardziej zwięzła, gdy używasz @Inject, która jest prawdziwa. Ale wyobraź sobie, że używasz klasy w teście. Następnie musisz ustawić wtrysk, aby uzyskać rejestrację. Z normalnym LoggerFactory dobrze działa również w testach. Jeśli java miałby ogólny mechanizm dla @Inject, to działałby świetnie, ale ponieważ jest to konfiguracja jest trudniejsza.