我有 Runnable 佇列，它在指定執行緒中一一呼叫。
val queue = LinkedBlockingQueue<() -> Unit>()
val queueThread = thread {
while(true)
queue.take().invoke()
}
我也有添加 Runnable 并等待它完成的功能。
fun invokeOnQueueThread(toInvoke: () -> Unit){
if(Thread.currentThread() == queueThread)
toInvoke()
else {
queue.offer(toInvoke)
// Some waiting code...
}
}
我測驗當前執行緒是否已經在我的佇列執行緒中，以防止不必要的鎖定本身。
所以，問題是：
Thread.currentThread()如果我非常非常頻繁地呼叫此代碼會導致性能問題嗎？
uj5u.com熱心網友回復：
JDK 本身依賴于 的性能Thread.currentThread()，因為這種方法在標準 Java 類別庫中被廣泛使用：特別是在ThreadLocal.get和ReentrantLock.lock其他 java.util.concurrent 原語中。
雖然Thread.currentThread()在 OpenJDK 中被標記為原生方法，但它并不是真正的 JNI 方法，而是JVM 內在方法。這意味著，JIT 編譯器將呼叫替換為高度優化的機器代碼。
在大多數 CPU 架構（x64、ARM 等）上，HotSpot JVM 有一個專用的 CPU 暫存器用于保存指向當前執行緒的指標。不是java.lang.Thread，而是表示 Java 執行緒的內部 VM 結構。反過來，這個結構持有對相應java.lang.Thread物件的參考。因此，在 JIT 編譯的代碼中，獲取對當前執行緒的參考只是從專用暫存器指向的結構中的一次加載。
例如，在 x64 上，暫存器 R15 在執行 Java 代碼時保存指向當前 VM 執行緒的指標，并且Thread.currentThread()呼叫被編譯為類似
mov 0x280(%r15),%r11
因此，呼叫Thread.currentThread()并不比讀取常規欄位慢，并且不應該是性能問題。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/468401.html