Warum @PostConstruct verwenden?

Question

In einer verwalteten Bohne, @PostConstruct wird nach dem regulären Java-Objektkonstruktor aufgerufen.

Warum sollte ich die @PostConstruct durch die Bohne zu initialisieren, anstatt durch den regulären Konstruktor selbst?

Answer 1

• denn beim Aufruf des Konstruktors ist die Bean noch nicht initialisiert, d.h. es sind noch keine Abhängigkeiten injiziert. In der @PostConstruct Methode ist die Bean vollständig initialisiert und Sie können die Abhängigkeiten verwenden.

• weil dies der Vertrag ist, der garantiert, dass diese Methode nur einmal im Lebenszyklus der Bohne aufgerufen wird. Es kann vorkommen (auch wenn es unwahrscheinlich ist), dass eine Bean vom Container in seiner internen Arbeit mehrfach instanziiert wird, aber es garantiert, dass @PostConstruct wird nur einmal aufgerufen.

Answer 2

En Haupt Problem ist das:

in einem Konstruktor, ist die Injektion der Abhängigkeiten noch nicht erfolgt*

_{*offensichtlich ohne Constructor Injection}

---

Ein Beispiel aus der Praxis:

public class Foo {

    @Inject
    Logger LOG;

    @PostConstruct
    public void fooInit(){
        LOG.info("This will be printed; LOG has already been injected");
    }

    public Foo() {
        LOG.info("This will NOT be printed, LOG is still null");
        // NullPointerException will be thrown here
    }
}

---

WICHTIG : @PostConstruct y @PreDestroy wurden vollständig in Java 11 entfernt .

Um sie weiterhin zu verwenden, müssen Sie die javax.annotation-api JAR zu Ihren Abhängigkeiten hinzufügen.

Maven

<!-- https://mvnrepository.com/artifact/javax.annotation/javax.annotation-api -->
<dependency>
    <groupId>javax.annotation</groupId>
    <artifactId>javax.annotation-api</artifactId>
    <version>1.3.2</version>
</dependency>

Gradle

// https://mvnrepository.com/artifact/javax.annotation/javax.annotation-api
compile group: 'javax.annotation', name: 'javax.annotation-api', version: '1.3.2'

Answer 3

Wenn Ihre Klasse ihre gesamte Initialisierung im Konstruktor durchführt, dann @PostConstruct ist in der Tat überflüssig.

Wenn Ihre Klasse jedoch ihre Abhängigkeiten mit Hilfe von Setter-Methoden injiziert, kann der Konstruktor der Klasse das Objekt nicht vollständig initialisieren, und manchmal muss eine Initialisierung durchgeführt werden, nachdem alle Setter-Methoden aufgerufen wurden, daher der Anwendungsfall von @PostConstruct .

Answer 4

Auch die konstruktorbasierte Initialisierung funktioniert nicht wie vorgesehen, wenn eine Art von Proxying oder Remoting beteiligt ist.

Die ct wird immer dann aufgerufen, wenn eine EJB deserialisiert wird und wenn ein neuer Proxy für sie erstellt wird...