public class MyThread implements Runnable { @Override public void run() { System.out.println(Thread.currentThread().getName()); } } public class Main { public static void main(String[] args) { MyThread mt = new MyThread(); new Thread(mt,"子線程對象").start(); mt.run(); } }
如上面代碼。
運行的時候輸出:
main
子線程對象
上面輸出結果中的"main"是執行mt.run();語句輸出的,
而"子線程對象"則是執行.start()語句輸出的。
也即前者代表着主進程,后者代表着子進程。
在HotSpot VM上,其實mt.run()幾乎總是會比.start()調用的run()要早執行,因為Thread.start()在調用(caller)線程上創建好線程就返回了,緊接着就可以去調用執行tt.m2();而在被調用(callee)的新線程上還要經過一些JVM內部的初始化動作才能跑到指定的入口方法。這並不是Java語言規范或者JVM規范所要求的行為,只是在HotSpot VM這種特定實現上會有這樣的特征,所以既不應該當作標准行為去依賴。
簡單點說就是:.start()新起一個線程去運行run方法,但是對main這個線程來說,他會繼續往下走 執行mt.run(),一個是新起線程去執行,一個是在本線程(已經在執行的線程)執行。(在程序運行時,主線程已經啟動並在運行中,而另外起一個線程start表示線程處於就緒狀態,還要等JVM機制調用進入運行狀態)
當時debug的時候輸出的結果卻是反過來。可能是:調用start之后,線程只是處於等待調度的“就緒”狀態,並沒有啟動。調試多線程最好用日志,調試器要么只暫停一個線程,要么全部掛起,容易讓人困擾的。
如果代碼中加一行,如下
new Thread(mt,"子線程對象").start(); Thread.yield(); mt.run();
效果就明顯了。
總結自網上。
