Per quali variabili tipi non devono mai essere statica?

Question

In una libreria che è in uso pesante nel nostro progetto v'è una restrizione che le variabili delle sue classi non devono mai essere statico. (E ' ULC ). Per quanto ho capito è a causa della necessità di serializzare tutti loro. E il problema con questa regola, è che non è rigorosa e può essere la causa di bug che sono molto difficili da eseguire il debug.

Stiamo per scrivere un modulo per Checkstyle per rilevare le variabili statiche di tali tipi (rilevati da alcuni regexp personalizzabile probabilmente). E abbiamo bisogno di sapere quanto sia necessario questo controllo per gli altri sviluppatori.

Quindi la domanda è:? Quali sono le circostanze generali in cui le variabili di alcuni tipi non devono mai essere statica

Answer 1

In primo luogo, il corretto oggetto di design orientato dovrebbe informare la decisione di fare un metodo statico / campo.

In secondo luogo, in un'applicazione web, in cui le richieste vengono gestite in thread separati, dovete essere molto attenti a come si utilizza statici metodi / campi. Se il metodo statico mantiene qualsiasi stato tra invocazioni (utilizzando un campo statico per mantenere un conteggio, per esempio), si può incorrere in problemi di threading. Ciò accade perché una richiesta potrebbe richiamare il metodo statico, e quindi essere fermato nel mezzo di esecuzione da un altro thread che richiama il metodo. Se la prima invocazione modificato una risorsa comune, ma non ha finito, il secondo potrebbe invocazione corrompere il progresso della prima esecuzione.

Answer 2

Risposta semplice: un tipo deve mai essere usato come istanza statico se sarà modificata in modo thread-pericoloso. Ho il sospetto che questo è il motivo per cui l'ULC raccomanda di non utilizzare i loro tipi in questo modo (non a causa di serializzazione).

Purtroppo, la selezione di questa con qualcosa come checkstyle è estremamente difficile. come esempio, HashMap non è thread-safe. tuttavia, se costruisco un'istanza e che lo staticly durante classe di carico e quindi sempre e solo letto dalla mappa successivamente, si tratta di un uso sicuro di HashMap (perché classloading fornisce la garanzia thread-sicurezza esterna sulla configurazione e non è mai successivamente modificato) .