2010-09-02 7 views
13

Tengo una clase que se parece a esto, y findbugz se queja del 'escribir en el campo estático del método de instancia' (initialize() y killStaticfield()). No puedo configurar el campo estático en el ctor.¿Cuál es la mejor manera de corregir este 'write to static field from instance method' findbugs warning?

  • ¿Cuál es la mejor solución para este problema?
  • ¿Sería suficiente con poner staticField en una AtomicReference?

    public class Something 
    { 
        private static SomeClass staticField = null; 
        private AnotherClass aClass; 
        public Something() 
        { 
    
        } 
    
        public void initialize() 
        { 
        //must be ctor'd in initialize 
        aClass = new AnotherClass(); 
        staticField = new SomeClass(aClass); 
        } 
    
        public void killStaticField() 
        { 
        staticField = null; 
        } 
    
        public static void getStaticField() 
        { 
        return staticField; 
        } 
    } 
    
+3

¿Por qué necesita ser 'static' en primer lugar? ¿Cuál es el requisito funcional? ¿Comprende de alguna manera qué significa "estático"? ¿Dígalo con sus propias palabras? – BalusC

+11

Sí, por supuesto que sé lo que significa estático; y no, no necesito demostrártelo. – darrickc

+0

Para responder a su pregunta, este campo es estático porque el método get debe ser estático para que otros objetos puedan acceder a staticField sin tener una referencia a un objeto Something. – darrickc

Respuesta

13

permanecer lo más cerca posible a su diseño original ...

public class Something { 
    private static volatile SomeClass staticField = null; 

    public Something() { 
    } 

    public static SomeClass getStaticField() { 
    if(Something.staticField == null) 
     Something.staticField = new SomeClass();; 
    return Something.staticField; 
    } 
} 

referencia a su variable estática a través del nombre de la clase, que eliminará el aviso findbugz. Marque su variable estática como volátil, lo que hará que la referencia sea más segura en un entorno multiproceso.

Aún mejor sería:

public class Something { 
    private static final SomeClass staticField = new SomeClass(); 

    public Something() { 
    } 

    public static SomeClass getStaticField() { 
    return Something.staticField; 
    } 
} 
+2

+1, prefiero la segunda versión incluso mejor. – emory

+0

Pero un diseño sin sincronizado también significa que no killStaticField. – extraneon

+0

Ya sabes ... En cuanto a la primera solución, todavía no es segura para subprocesos, aunque la variable sea volátil.Tendría que poner un bloque {} sincronizado alrededor de la sección if-null-then-new ... Definitivamente preferiría la segunda opción. – romacafe

4

La cuestión es lo que quiere hacer con el campo estático. Si cambia para cada clase que crees, puede que no sea una buena idea tenerlo estático. Si se inicializa solo una vez, debería inicializarlo como un singleton.

public class Something 
{ 
    private static SomeClass staticField = null; 

    public Something() 
    { 

    } 

    public static SomeClass getStaticField() 
    { 
     if(staticField == null) 
      staticField = new SomeClass();; 
     return staticField; 
    } 
} 
+0

¡No olvide hacer que el método 'getStaticField' esté sincronizado! –

+0

Y tenga en cuenta que no se puede simplemente sincronizar en la definición del método estático, ya que los métodos estáticos usan Something.class para sincronizarse. – darrickc

+1

Creo que el uso de variables estáticas debe ser claro antes de discutir cualquier problema de subprocesamiento avanzado. Y lo siento, pero su pregunta realmente no suena como si entendiera cuándo usar variables estáticas y cuándo no. Tal vez puedas aclarar tu pregunta un poco más. – Daff

4

Elimina la estática de staticField si no debería ser estática.

Make kill y getStaticField static. Y normalmente hace referencia a la estática por el nombre de la clase, no por una (implícita) esto, para dejar muy claro que es estático y puede causar consecuencias inesperadas en otros thReads.

En caso de duda, no utilice estadísticas para campos no constantes.

+0

No necesita el "En caso de duda". –

Cuestiones relacionadas