不可變和線程安全
大多數線程安全問題，來源自對可變對象的并發讀寫。以下是一個在java中的典型并發問題代碼片段：
如果多個線程調用同一個SomeExampleClass對象的getThisOrThat方法時，就會出現一個典型的競爭條件。當第二個線調用此方法并嘗試讀取mCount變量時，第一個線程此時可能正在執行mCount++操作，因此，我們就無法確定第二個線程將會讀取到什么值。這個問題的根本原因，就是多個線程嘗試讀寫了一個可變對象mCounter。一般來說，當我們遇到將計算分配到各個不同線程中去計算的問題時，競爭條件是最常見的問題。
競爭條件的存在，導致了在多線程中處理UI問題變得特別復雜。在Android中，view對象都都是富有狀態并且狀態可被改變。例如TextView，在保持當前文本的同時，需要給開發者暴露setText()的方法，允許改變其狀態。這意味著在Android系統中，如果UI框架打算在其他線程中執行耗時計算（如layout）時，框架就必須解決在耗時計算的同時，對象的狀態可能被其他線程修改的問題。
讓我們暫時回到我們的示例代碼上。之前我們闡述過，主要問題是來源于getThisOrThat()方法中訪問了一個可變對象mCounter。因此，是否可以找到一個功能上等價但是不用依賴這些可變狀態的方法實現？我們先設想存在一個，一旦創建，就無法改變的對象。在這樣的對象中，如果沒有狀態可以被修改，那么我們就不會出現之前提到的競爭條件。我們嘗試重寫之前的示例代碼：
目前，SomeExampleClass中不再存在任何可以被修改的狀態，因此可以說，這個方法是完全線程安全的。getThisOrThat()方法可以被稱做一個純凈的函數(‘pure function')，其返回的結果僅僅依賴于輸入參數而不產生任何副作用。
在Litho中，我們試圖在layouti計算中，嚴格應用相同的概念。一個Compoent是一個包含了所有layout計算相關參數（使用注解@Prop和@State標記）的不可變對象。這也解釋了為什么我們需要@Prop和@State注解來實現不可變，如果不存在這些注解，我們就無法把layout計算作為一個純凈的函數(‘pure function')
同步和異步操作
Litho為layout計算提供了同步和異步的APIs。這兩個API都是線程安全的，并且可以通過任意線程去調用。最終的layout總是由最后一次setRoot()或者setRootAsync()方法的調用決定。
同步layout計算保證在ComponentTree調用setRoot()后，計算結果能立刻被加載到LithoView中。而這種計算的主要缺點在于，計算會發生在被調用的線程。因此，在主線程調用setRoot()是不建議的。另外，在某些情況下，你可能不允許等待后臺線程計算完畢再顯示到屏幕上，此時同步的調用setRoot()是最好的解決辦法。支持同步操作使得Litho能夠很容易的和現有的線程模型兼容。如果你的應用已經具有了一個復雜的線程設計，你可能不想將layout計算移植到Litho內建的線上中去計算。
異步layout計算將允許Litho使用layout thread去計算Component layout。這意味著，計算工作將會被立刻放到一個計算隊列當中，而計算結果不會立刻出現在調用者線程中。異步layout計算的樣例可以在RecyclerBinder中查看。
