sirve - ¿Por qué hacer un método volátil en java?

settooltiptext java para que sirve

Question

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

Edición: hice un toString () en un objeto Method devuelto por un objeto de clase (Java Reflection). La cadena de retorno tenía un modificador volátil en comparación con el nombre del método junto con la visibilidad pública y el tipo de retorno nulo. La investigación arrojó solo información sobre volátiles para propiedades. Por eso hice esta pregunta.

La declaración del método fue:

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

Código 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());
            }
        }
    }
}

Invocación del método:

Test.showMethods(mapView);

Answer 1

En primer lugar, no hay métodos volatile en Java. Parada completa

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

Un campo se puede declarar volátil, en cuyo caso el modelo de memoria Java garantiza que todos los subprocesos ven un valor coherente para la variable.

Ahora, si intentamos traducirlo a métodos : en el caso de un método volátil, algo aseguraría que todos los hilos vean un código de bytes consistente para el método. Pero eso está garantizado de todos modos. Los subprocesos no ven versiones diferentes de una clase, todos ven 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 2

Has leído

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

Solo para completar la respuesta:

Como todos los demás están señalando: no se puede hacer un método volátil.

Answer 3

Investigué un poco y mis conclusiones se parecen mucho a las de Cowan. El siguiente código produce la salida correcta en un Sun JDK 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()

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

Los interesados ​​en el Android Jar pueden descargarlo 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 4

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

Answer 5

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

Answer 6

Sospecho firmemente que lo que está viendo es un efecto secundario del hecho de que JLS define el siguiente bit para los campos:

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 llama por ejemplo, Modifier.toString(int) sin, como sugiere la documentación:

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

luego obtendrá una salida inadecuada (incluidos los métodos de puente, generados automáticamente para, por ejemplo, el tipo de retorno covariante, que aparece como ''volátil'').

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

Answer 7

Usted no puede volatile es solo un modificador valido para un campo.