2014-09-11 14 views
8

Si può caricare una classe dinamicamente utilizzando questo metodo di java.lang.Class:Quando devono essere inizializzate le classi - al momento del caricamento o al primo utilizzo?

public static Class<?> forName(String name, boolean initialize, 
           ClassLoader loader) 

Secondo the JavaDoc, il secondo parametro viene utilizzato per controllare i tempi di inizializzazione classe (esecuzione di codice di inizializzazione statico). Se true, la classe viene inizializzata dopo il caricamento e durante l'esecuzione di questo metodo; se false, l'inizializzazione viene ritardata fino al primo utilizzo della classe.

Ora capisco tutto questo, ma i documenti non dicono come decidere quale strategia utilizzare. È meglio fare sempre l'inizializzazione immediatamente? È meglio ritardarlo sempre al primo utilizzo? Dipende dalle circostanze?

+2

Bene, se si passa 'false', la classe verrà * inizializzata * al primo utilizzo (pigro). Se si passa 'true', la classe verrà inizializzata durante il * caricamento * (non appena il caricamento è completato). Passa 'true' quando sei sicuro che la classe verrà utilizzata nelle prossime righe di codice. Passa 'false' se esiste una buona probabilità che la classe non possa essere utilizzata. – TheLostMind

+0

@icza, "inizializzato" è l'ortografia corretta per il mio dialetto di inglese (australiano).Non è stato necessario modificare la mia domanda per cambiarla. –

+0

@Kissane Ok, scusate, pensavo che solo "inizializzato" fosse corretto. – icza

risposta

5

Sì, dipende dalle circostanze, ma in genere è preferibile lasciare solo le classi caricate e inizializzate al primo utilizzo.

casi in cui si potrebbe desiderare di loro inizializzare precoce (ad esempio chiamando forName() per loro):

  • blocchi di inizializzazione statico potrebbe eseguire i controlli per le risorse esterne (ad esempio i file, di connessione al database), e se tali fallire, non vuoi nemmeno continuare l'esecuzione del tuo programma.
  • Simile al precedente: caricamento di librerie native esterne. Se falliscono (o non sono adatti per la piattaforma corrente), potresti rilevarlo presto e non continuare con la tua app.
  • I blocchi di inizializzazione statici possono eseguire lunghe operazioni e non si desidera avere ritardi/ritardi in seguito quando sono realmente necessari, è possibile inizializzarli in anticipo o su thread di sfondo diversi.
  • Se si dispone di file di configurazione statici in cui i nomi delle classi sono specificati come testo, è possibile inizializzarli/caricarli in anticipo per rilevare errori di configurazione/errori di battitura. Tali esempi sono file di configurazione del logger, web.xml, contesto di primavera ecc.
  • Molte classi nella cache standard di Java memorizzano alcuni dati come lo HTTPUrlConnection nella cache dell'agente utente HTTP restituito da System.getProperty("http.agent"). Quando viene utilizzato per la prima volta, il suo valore verrà memorizzato nella cache e se lo si modifica (con lo stesso valore System.setProperty()), il nuovo valore non verrà utilizzato. È possibile forzare tale memorizzazione nella cache se si inizializzano le classi corrette in anticipo, proteggendole in seguito dal codice.

Casi in cui non si dovrebbe inizializzare presto:

  • classi che potrebbe essere solo bisogno in rari casi, o potrebbe anche non essere necessari a tutti per tutta la corsa della vostra applicazione. Ad esempio, un'applicazione GUI potrebbe mostrare solo la finestra di dialogo Informazioni quando l'utente seleziona il menu Guida/Informazioni. Ovviamente non è necessario caricare le classi pertinenti in anticipo (ad esempio AboutDialog) perché si tratta di un caso raro e nella maggior parte delle sessioni l'utente non lo farà/ne avrà bisogno.
+0

+1. Un buon esempio di quest'ultimo scenario: si dispone di un servizio Web che segnala a un servizio di bilanciamento del carico quando è pronto per il traffico; i blocchi di inizializzazione statici eseguono operazioni necessarie ma costose prima di inviare questo segnale, ad es. per l'innesco della cache. –

+1

solo per curiosità, * perché qualcuno dovrebbe mettere operazioni * a lungo termine in blocchi * statici *? – TheLostMind

+0

@TheLostMind Un'operazione a lungo termine potrebbe essere la lettura e la memorizzazione nella cache dei dati dal database o l'accesso a un server Web (ad esempio il controllo degli aggiornamenti). È discutibile se è davvero necessario essere statici, ma potrebbero esserci casi in cui qualcuno decide di farlo. – icza

Problemi correlati