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();
 

效果就明顯了。

總結自網上。

主線程和子線程執行順序問題