Java Singleton vs statico: esiste un reale vantaggio in termini di prestazioni?

Question

Sto unendo un ramo CVS e uno dei cambiamenti più grandi è la sostituzione, ovunque si verifichi, di un pattern Singleton con classi astratte che hanno un blocco di inizializzazione statico e tutti i metodi statici.

Vale la pena mantenerlo poiché richiederà l'unione di molti conflitti, che tipo di situazione dovrei considerare affinché questo refactoring valga la pena?

Stiamo eseguendo questa app con Weblogic 8.1 (quindi JDK 1.4.2)

---

scusa Thomas, lasciami chiarire..

la versione HEAD ha il modello singleton tradizionale (costruttore privato, getInstance() ecc.)

la versione del ramo non ha costruttore, è una "classe astratta pubblica" e ha modificato tutti i metodi sull'oggetto in modo che siano "statici".Il codice che esisteva nel costruttore privato viene spostato in un blocco statico.

Quindi tutti gli utilizzi della classe vengono modificati, causando più conflitti nell'unione.

Ci sono alcuni casi in cui è stata apportata questa modifica.

Answer 1

Da un punto di vista strettamente prestazionale in termini di runtime, la differenza è davvero trascurabile.La differenza principale tra i due risiede nel fatto che il ciclo di vita "statico" è collegato al classloader, mentre per il singleton è un ciclo di vita di istanza regolare.Di solito è meglio stare alla larga dal business di ClassLoader, si evitano alcuni problemi complicati, soprattutto quando si tenta di ricaricare l'applicazione web.

Answer 2

Utilizzerei un singleton se fosse necessario memorizzare qualsiasi stato e altrimenti le classi statiche.Non ha senso creare un'istanza di qualcosa, anche di una singola istanza, a meno che non sia necessario archiviare qualcosa.

Answer 3

La statica è dannosa per l'estensibilità poiché i metodi e i campi statici non possono essere estesi o sovrascritti dalle sottoclassi.

È anche un male per i test unitari.All'interno di uno unit test non è possibile evitare che gli effetti collaterali di diversi test si riversino poiché non è possibile controllare il classloader.I campi statici inizializzati in uno unit test saranno visibili in un altro o, peggio ancora, l'esecuzione simultanea dei test produrrà risultati imprevedibili.

Singleton è generalmente un modello ok se usato con parsimonia.Preferisco utilizzare un framework DI e lasciare che gestisca le mie istanze per me (possibilmente in ambiti diversi, come in Guice).

Answer 4

Se il mio post originale era interpretato correttamente e la discussione di Sun a cui era collegato è accurata (cosa che penso potrebbe essere), allora penso che devi fare un compromesso tra chiarezza e prestazioni.

Poniti queste domande:

1. L'oggetto Singleton rende più chiaro quello che sto facendo?
2. Ho bisogno di un oggetto per svolgere questa attività o è più adatto ai metodi statici?
3. Ho bisogno delle prestazioni che posso ottenere non utilizzando un Singleton?

Answer 5

Dalla mia esperienza, l'unica cosa che conta è quale è più facile da deridere nei test unitari.Ho sempre pensato che Singleton fosse più facile e naturale da prendere in giro.Se la tua organizzazione ti consente di utilizzare JMockit, non importa poiché puoi superare queste preoccupazioni.

Answer 6

Questa discussione aiuta?(Non so se sia tabù collegarsi a un altro forum di programmazione, ma preferirei non limitarmi a citare l'intera discussione =))

Sole Discussione su questo argomento

Il verdetto sembra essere che nella maggior parte dei casi non fa una differenza sufficiente, anche se tecnicamente i metodi statici sono più efficienti.

Answer 7

Scrivi del codice per misurare le prestazioni.La risposta dipenderà dalla JVM (il JDK di Sun potrebbe funzionare in modo diverso da JRockit) e dai flag VM utilizzati dall'applicazione.