2016-08-03 25 views
2

Ich bin relativ neu zu ThreadPoolExecutor. Ich sehe, ob ich das Runnable vor dem Ausführen und in nachExecute verfolgen kann.ScheduledThreadPoolExecutor afterExecute Runnable.toString ist anders

Mit runnable.toString() mit afterExecute(Runnable t, Throwable t). Jetzt merke ich, dass ich einfach ein Log in das Runable selbst schreiben konnte ... aber ich war neugierig was diese Methode hervorbringen würde.

Für ThreadPoolExecutor, funktioniert gut, runnable.toString ist das gleiche vor execute(runnable) und auch in afterExecute().

Jedoch! ScheduledThreadPoolExecutor ist anders. Seine afterExecute runnable.toString ist ganz anders.

Zum Beispiel vor: [email protected], AfterExecute: java.[email protected]zxc

Nicht einmal der PKG-Name ist das gleiche. Warum ist das?

private MyThreadPool() { 
    threadPool = new ThreadPoolExecutor(NUMBER_OF_CORES, MAX_CORES, 
     KEEP_ALIVE_TIME, KEEP_ALIVE_TIME_UNIT, workQueue) { 
     @Override 
     public void afterExecute(Runnable r, Throwable t) { 
      super.afterExecute(r, t); 
      Log.d(TAG, "ThreadOps onDone: " + r.toString()); 
      // (A) will return same --> [email protected] 
     } 
    }; 
    threadPool.setRejectedExecutionHandler(rejectedHandler); 

    scheduledThreadPool = new ScheduledThreadPoolExecutor(NUMBER_OF_CORES) { 
     @Override 
     public void afterExecute(Runnable r, Throwable t) { 
      super.afterExecute(r, t); 
      Log.d(TAG, "ThreadOps onDelayDone: " + r.toString()); 
      // (D) does not return same? 
      // I am expecting --> [email protected] , but get... 
      // java.[email protected]zxc 
     } 
    }; 
    scheduledThreadPool.setRejectedExecutionHandler(rejectedHandler); 
} 

public void execute(Runnable runnable) { 
    Log.d(TAG, "ThreadOps exe: " + runnable.toString()); 
    // (A) lets say toString --> [email protected] 
    threadPool.execute(runnable); 
} 

public void delayExecute(Runnable runnable, long delayms) { 
    Log.d(TAG, "ThreadOps exe @" + delayms + ": " + runnable.toString()); 
    // (D) lets say toString --> [email protected] 
    scheduledThreadPool.schedule(runnable, delayms, TimeUnit.MILLISECONDS); 
} 

Antwort

1

ScheduledThreadPoolExecutor führt intern einen Haufen Sorten zu leicht hinzufügen und eingereichten Aufgaben abrufen, basierend auf den geplanten (dh. Derjenige, der nächste an der Spitze des Haufens ausgeführt werden muss).

Zugriff auf diese Haufen zu helfen, schmückt die Umsetzung der ScheduledThreadPoolExecutor die Runnable oder Callable Instanzen Sie schedule mit einer benutzerdefinierten Implementierung, die ihre Position in dem Heap unter anderem beschreibt. Das ist die ScheduledFutureTask, die Sie in Ihren Protokollen sehen. Beachten Sie, dass dies ein Implementierungsdetail ist (es ist eine private Klasse) und Sie sollten sich nicht darauf verlassen.

+0

Vielen Dank. Ich sehe, also wird es in eine andere Klasse umgewandelt und dann von dort ausgeführt, das erklärt, warum sich der toString komplett verändert hat. – TWL