2010-03-13 13 views
10

¿Hay alguna manera de comprobar cuántos subprocesos están esperando que se desbloquee un método sincronizado?Cómo comprobar cuántos subprocesos están esperando que se desbloquee un método sincronizado

Me gustaría saber cuando el hilo se llama a un método sincronizado:

1) ¿Cuántos hilos ya están esperando para llamar al método?

2) Una vez que se llama al método ¿cuánto tiempo tuvo que esperar para desbloquear el método?


Solución: He resuelto esto utilizando apiladores responden:

public class LockedClass { 
    public static int count; 
    public static void measuringClass() throws IOException{ 
     long startTime = System.currentTimeMillis(); 
     count++; 
     System.out.println("Threads waiting="+count); 
     lockedMethod(startTime); 
     count--; 
     System.out.println("Threads waiting="+count); 
    } 
    public static synchronized void lockedMethod(long startTime) throws IOException{ 
     System.out.println("I spent="+(System.currentTimeMillis()-startTime)+" in the queue"); 
     Hashtable<String, String> params = new Hashtable<String, String>(); 
     params.put("param1", "test"); 
     params.put("param2", "12345678"); 
     String sessionId = Common.getSession(Common.executeHttpRequest(params)); 
    } 
} 
+1

'count' no está sincronizado, no obtendrá un recuento preciso en una situación de múltiples hilos. utilice 'AtomicInteger' – irreputable

Respuesta

2

Se puede transformar el código para utilizar un bloque sincronizado en lugar de métodos sincronizados, aquí es mi borrador. No estoy seguro si coincide con su segundo requisito (debido a mi inglés entrecortado)

public class Sync { 
    public static int waiting = 0; 
    private Object mutex = new Object(); 

    public void sync() { 
     waiting++; 
     synchronized (mutex) { 
      waiting--; 
      long start = System.currentTimeMillis(); 
      doWhatever(); 
      System.out.println("duration:" 
        + (System.currentTimeMillis() - start)); 
     } 
    } 
} 
+0

Gracias, utilicé una variación de esto para lograr lo que quería –

+1

Odio a -1, pero tiene una condición de carrera con 'esperando ++;' allí ... Y la visibilidad entre hilos tampoco está garantizada. Esto podría causar un comportamiento indeterminable y no es bueno. Recomiendo la respuesta de Brabster (no el semáforo, pero este: http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/ReentrantLock.html#getQueueLength%28% 29) –

+0

No entiendo por qué la variable de espera no está sincronizada también? También es la declaración de espera ++ segura? – Rabiees

4

1) que no creen que es posible tener este nivel de visibilidad en su código. Java proporciona un powerful concurrency API más que proporciona un control y una visibilidad mucho más directos. Como punto de partida, hay un semáforo de clase que tiene un método getQueueLength() que suena como si fuera lo que quieres.

2) Cuando se llama a un método sincronizado, el hilo de llamada esperará hasta que se desbloquee el método, cuánto tiempo demorará depende de cuánto tarda el código con el bloqueo en hacer su trabajo. Cuando espera() en un objeto, puede especificar un tiempo de espera. No creo que puedas hacer eso con un método sincronizado.

+0

+1. Diría que 'ReentrantLock' es más adecuado en este caso que un' Semaphore'. –

1

Creo que Java Thread Validator puede proporcionar alguna información sobre estas cuestiones.

No da exactamente esas estadísticas, pero sí le indicará la frecuencia sucede contención y lo que el tiempo de espera es etc.

Cuestiones relacionadas