用QThread啟動執行緒的良好方法以及理解。

1) 用原始的QThread的started訊號觸發自定義的slot啟動執行緒，而不是派生QThread的類過載run函式啟動執行緒。

將一個類派生自QObject，然後實現所有的signal/slot，然後通過呼叫movetothread函式來使他們執行在新的執行緒裡面，而不是每次都要重新派生QThread，並且派生QThread的另外一個不好的地方是隻有run函式內部的程式碼才會執行在新執行緒裡面，相比起來，派生QObject並使用movetothread函式更具有靈活性。

2) 自定義物件moveToThread進執行緒後，事件迴圈可以完全在此執行緒中執行。而它的記憶體管理應該還屬於主執行緒。
 

如下例子中（MyObject*myObj）被moveToThread進執行緒（QThread*thread）。假如物件（MyObject*myObj）有父親，它不能移動這種關係。在另一個執行緒(而不是建立它的那個執行緒)中delete QObject物件是不安全的。除非你可以保證在同一時刻物件不在處理事件。可以用QObject::deleteLater(),它會投遞一個DeferredDelete事件，這會被物件執行緒的事件迴圈最終選取到。

3）exec的重要性。

主執行緒開始它的事件迴圈需要呼叫QCoreApplication::exec(), 子執行緒需要用QThread::exec()，功能基本是一樣的，當然qt內部肯定是不同的實現。
 

假如沒有事件迴圈執行，事件不會分發給物件。舉例來說，假如你在一個執行緒中建立了一個QTimer物件，但從沒有呼叫過exec(),那麼QTimer就不會發射它的timeout()訊號.對deleteLater()也不會工作。(這同樣適用於主執行緒)。

4) 子執行緒接收事件

a) 如下例子中，子執行緒並不存在exec()函式。原因是exec()函式在QThread的run()中呼叫了。

我們這裡並沒有做一個QThread派生類，在run中呼叫exec()。因為我不推薦怎麼幹。原因很簡單，並不需要這麼幹。進一步說明是：qt提供的QThread已經完全滿足執行緒建立的需要。為什麼還要自己再畫蛇添足呢。
 

b)本例子真正使用的是QCoreApplication::postEvent，和過載QObject類的customEvent的方法。訊息一樣會在（MyObject*myObj）所在的執行緒處理。

5) 關於QCoreApplication::postEvent和QCoreApplication::sendEvent

postEvent: 可以給別的執行緒傳送事件。事件會在目的物件所屬的執行緒中執行。這是一個非同步介面。
sendEvent: 僅用於同一個執行緒之間傳送事件。目的物件必須與當前執行緒一樣。這是一個同步介面。假如傳送給屬於另一個執行緒的物件，會報錯：ASSERT failure in QCoreApplication::sendEvent: "Cannot send events to objects owned by a different thread. Current thread a51f48. Receiver '' (of type
 'MyObject') was created in thread a3bf18", file kernel\qcoreapplication.cpp, line 539

以下是結合上述描述的3個檔案。可正常編譯執行。