¿Por qué hacer un método volátil en Java?

Question

¿Por qué se volvía volátil un método? ¿Cómo cambia un método volátil el comportamiento del método?

Editar: Hice un toString() en un objeto de método devuelto por un objeto de clase (reflexión de Java). La cadena de retorno tenía un modificador volátil contra el nombre del método junto con la visibilidad pública y el tipo de devolución nula. La investigación arrojó solo información sobre las propiedades volátiles. Es por eso que hice esta pregunta.

La declaración de método era:

Código

public volatile org.osmdroid.api.IGeoPoint org.osmdroid.views.MapView.getMapCenter() 

para el método de reflexión:

public static class Test { 
    public static void showMethods(Object target) { 
     Class<?> clazz = target.getClass(); 
     for (Method method : clazz.getMethods()) { 
      if (method!=null) { 
       System.out.println(method.toString()); 
      } 
     } 
    } 
} 

Método de invocación:

Test.showMethods(mapView); 

Answer 1

tengo la fuerte sospecha de que lo que se está viendo es un efecto secundario del hecho de que el JLS se definen los siguientes campos de bits para:

public static final int VOLATILE = 0x00000040; 

y el siguiente bit para métodos:

static final int BRIDGE = 0x00000040; 

Tenga en cuenta que tienen el mismo valor (el mismo bit tiene un significado diferente para los métodos y campos).

Si llamas, p. Modifier.toString(int) sin que, como la documentación sugiere:

Tenga en cuenta que para realizar tal comprobación de un tipo conocido de la entidad, como un constructor o método, en primer lugar y el argumento de toString con la máscara apropiada en un método como constructorModifiers o methodModifiers.

y obtendrá resultados inadecuados (incluidos los métodos de puente, autogenerados para, por ejemplo, el tipo de retorno covariante, que aparecen como 'volátiles').

Al menos el actual OpenJDK Method.toString() lo filtra; si el tuyo no lo es, quizás estés usando una versión diferente o anterior del JDK que no hace esto correctamente.

Answer 2

No se puede. volatile es solo un modificador válido para un campo.

Answer 3

No puede hacer que un método sea volátil. No compilará

Answer 4

¿Ha leído

http://jeremymanson.blogspot.com/2008/11/what-volatile-means-in-java.html

---

sólo para la completa respuesta:

como todo el mundo está señalando: no se puede hacer un método volátil.

Answer 5

En primer lugar, no volatile métodos en Java. Punto final.

Java permite declarar los campos como volatile. La especificación del lenguaje Java explica el propósito:

Un campo puede declararse volátil, en cuyo caso el modelo de memoria Java garantiza que todos los subprocesos vean un valor constante para la variable.

Ahora, si tratamos de traducir a métodos: en caso de un método volátil algo aseguraría que todos los hilos de ver un código de bytes coherente para el método. Pero eso está garantizado de todos modos. Los hilos no ven diferentes versiones de una clase, todos ellos ver el mismo código de bytes (compilado) (siempre que no jueguen trucos con los cargadores de clases ...).

Así que no hay necesidad de métodos volatile en Java.

Answer 6

Hice algunas investigaciones y mis conclusiones reflejan de cerca a Cowan. El siguiente código produce la salida correcta en un JDK de Sun 1.6_13

public void go() 
{ 

    try 
    { 
     Class<?> forName = Class.forName("org.osmdroid.views.MapView"); 
     Method[] methods = forName.getMethods(); 
     for(Method m : methods) 
     { 
      String name = m.getName(); 
      if(name.equals("getMapCenter")) 
      { 
       System.out.println(m); 
      } 
     } 
    } 
    catch (Exception e) 
    { 
     e.printStackTrace(); 
    } 
} 

salida

public org.osmdroid.api.IGeoPoint org.osmdroid.views.MapView.getMapCenter() 
public org.osmdroid.util.GeoPoint org.osmdroid.views.MapView.getMapCenter() 

Lo JDK está usando y qué versión es? La lógica utilizada para construir el Método toString() sería interesante de leer detenidamente.

Las personas interesadas en el tarro de Android pueden descargar desde aquí

http://code.google.com/p/osmdroid/downloads/list http://www.jarvana.com/jarvana/archive-details/com/google/android/android/1.5_r3/android- 1.5_r3.jar

Answer 7

Parece que los métodos "volátiles" son producidos bajo el capó por el compilador de Java, como "métodos de pegamento" para los métodos genéricos. Generics producirá bajo los métodos hood que aceptará solo Object como parámetros y los convertirá al tipo genérico específico, mientras que estos métodos son invisibles para el desarrollador. Sin embargo, hay una manera más segura de determinar estos métodos, usando el method.isBridge()