歌者沒有太多的抱怨，生存需要投入更多的思想和精力。
宇宙的熵在升高，有序度在降低，像平衡鵬那無邊無際的黑翅膀，向存在的一切壓下來，壓下來。可是低熵體不一樣，低熵體的熵還在降低，有序度還在上升，像漆黑海面上升起的磷火，這就是意義，最高層的意義，比樂趣的意義層次要高。要維持這種意義，低熵體就必須存在和延續。
對科幻有一點了解的朋友也許已經猜到，這段描寫出自《三體》。這想必是整部《三體》中最燒腦的一段文字了。
歌者反覆提到的“低熵體”，到底是一個怎樣的存在呢？要理解它，我們首先要來講講“熵”這個概念。
據說，在很多物理學家的眼中，科學史上出現的最重要的物理規律，既不是牛頓三大定律，也不是相對論或者宇宙大爆炸理論，而是熱力學第二定律。它在物理規律中具有至高無上的地位，因為它從根本上支配了我們這個宇宙演化的方向。這個定律指出：任何孤立系統，只能沿著熵增加的方向演化。
什麼是熵？通俗來講，可以理解為物體或系統的無序狀態，或者混亂程度（亂度）。在沒有外力干涉的情況下，隨著時間的推移，一個系統的亂度將會越來越大。將冰塊投入溫水中，它終將融化，並與水交融為一體，因為溫水的無序程度要高於冰塊；一副撲克牌，即使按照花色和大小排列整齊，但經過多次隨機的洗牌之後，它終將變得混亂無序；一間乾淨整潔的房間，如果長期沒有人收拾的話，它將會變得髒亂不堪。
而生命體，尤其是智慧生命體（比如人類），卻是典型的“低熵體”，能夠維持自身和周圍環境長期處於低熵的狀態。可以想象，如果一所房子能夠長期保持乾淨整潔，多半是因為它有一位熱愛整潔且勤於家務的女主人。
縱觀整個人類的發展史，人們將荒野開墾成農田，將河流疏導成生命的水源，結束散居生活從而聚整合村落。同時，人類又花費了數千年的時間，建立起輝煌的城市文明。城市道路和建築樓群排列有致，軌道交通也井然有序；城市的地下管線錯綜複雜，為每家每戶輸送水電能源；清潔工人每天清掃垃圾，並將它們分門別類，運往恰當的處理地點……
所有的這一切，得以讓我們這個世界遠離無序狀態，將熵值維持在一個很低的水平。
但是，一旦離開人類這個“低熵體”的延續和運轉，這一切整齊有序都將不復存在。甚至是當人類的單個個體死亡之後，它的有機體也再不能維持自身。它終將隨著時間腐爛，最終化為泥土。
記得在開發微愛App的過程中，我們曾經實現過這樣一個主題皮膚的功能：
按照上面的截圖所示，使用者可以將軟體的顯示風格設定成多種主題皮膚中的一個（上面截圖中顯示了8個可選的主題）。當然，使用者同一時刻只能選中一個主題。
我們的一位工程師按照這樣的思路對儲存結構進行了設計：每個主題用一個物件來表示，這個物件裡儲存了該主題的相關描述，以及該主題是否被使用者選中（作為當前主題）。這些物件的資料最初都是從伺服器獲得的，都需要在本地進行持久化儲存。物件的資料結構定義如下（偽碼）：
/**
* 表示主題皮膚的類定義。
*/
public class Theme {
//該主題的ID
public int themeId;
//該主題的名稱
public String name;
//該主題的圖片地址
public String picture;
//其它描述欄位
......
//該主題是否被選中
public boolean selected;
}
/**
* 全域性配置：儲存的各個主題配置資料。
* 從持久化儲存中獲得。
*/
Theme[] themes = getFromLocalStore();複製程式碼上面截圖介面中的主題選中狀態的顯示邏輯如下（偽碼）：
//輸入引數：
//介面中顯示各個主題的View層控制元件
View[] themeViews;
......
for (int i = 0; i < themeViews.length; i++) {
if (themes[i].selected) {
//將第i個主題顯示為選中狀態
displaySelected(themeViews[i]);
}
else {
//將第i個主題顯示為未選中狀態
displayNotSelected(themeViews[i]);
}
}複製程式碼而使用者重新設定主題的時候，選中邏輯如下（偽碼）：
//輸入引數：
//介面中顯示各個主題的View層控制元件
View[] themeViews;
//當前使用者要選擇的新主題的下標
int toSelect;
......
//找到舊的選中主題
int oldSelected = -1;
for (int i = 0; i < themes.length; i++) {
if (themes[i].selected) {
oldSelected = i; //找到了
break;
}
}
if (toSelect != oldSelected) {
//修改當前選中的主題資料
themes[toSelect].selected = true;
//將當前選中的主題顯示為選中狀態
displaySelected(themeViews[toSelect]);
if (oldSelected != -1) {
//修改舊的選中主題的資料
themes[oldSelected].selected = false;
//將舊的選中主題顯示為非選中狀態
displayNotSelected(themeViews[oldSelected]);
}
//最後，將修改後的主題資料持久化下來
saveToLocalStore(themes);
}複製程式碼這幾段程式碼看起來是沒有什麼邏輯問題的。但是，在使用者使用了一段時間之後，有使用者給我們發來了類似如下的截圖：
竟然同時選中了兩個主題！而我們自己不管怎樣測試都重現不了這樣的問題，檢查程式碼也沒發現哪裡有問題。
這到底是怎麼回事呢？
經過仔細思考，我們終於發現，按照上面這個實現，系統具有的“熵”比它的理論值要稍微高了一點。因此，它才有機會出現這種亂度較高的狀態（兩個同時選中）。
什麼？一個軟體系統也有熵嗎？各位莫急，且聽我慢慢道來。
熱力學第二定律，我們通俗地稱它為熵增原理，乃是宇宙中至高無上的普遍規律，在程式設計世界當然也不例外。
為了從程式設計師的角度來解釋熵增原理的本質，我們仔細分析一下前面提到過的撲克牌洗牌的例子。我第一次看到這個例子，是在一本叫做《悖論：破解科學史上最複雜的9大謎團》的書上看到的。再也沒有例子能夠如此通俗地表現熵增原理了。
從花色和大小整齊排列的一個初始狀態開始隨機洗牌，撲克牌將會變得混亂無序；而反過來則不太可能。想象一下，如果我們拿著一副徹底洗過的牌，繼續洗牌，然後突然出現了花色和大小按有序排列的情況。我們一定會認為，這是在變魔術！
系統的演變為什麼會體現出這種明確的方向性呢？本質上是系統狀態數的區別。
花色和大小有序排列，只有一種情況，所以狀態數為1；而混亂無序的排列方式的數量，是一個非常非常大的值。稍微應用一點組合數學的知識，我們就能算出來，所有混亂無序的排列方式，總共有(54!-1)種，其中(54!)表示54的階乘。混亂的狀態數多到數不勝數，因此隨機洗牌過程總是使牌序壓倒性地往混亂無序的方向發展。
而混亂無序的反面——整齊有序，則本質上意味著對於系統可取狀態數的限制。對於所有54張牌，我們限制只能取一種特定的排列，就意味著整齊。同樣，在整潔的房間裡，一隻襪子不會出現在鍋裡，或者其它任意地方，也是一種對於可取狀態的限制。
我們程式設計的過程，就是根據每一個條件分支，逐漸細化和限制系統的混亂狀態，從而最終達到有序的一個過程。我們構建出來的系統，對於可取狀態數的限制越強，系統的熵就越低，它可能達到的狀態數就越少，就越不可能進入混亂的狀態（也是我們不需要的狀態）。
回到剛才主題皮膚的那個例子，假設總共有8個主題，按前面的實現，每個主題都有“選中”和“未選中”兩個狀態。那麼，系統總的可取狀態數一共有“2的8次方”個，其中有8個狀態是我們所希望的（也就是有序的狀態，分別對應8個主題分別被選中的情況），剩餘的(2的8次方-8)個狀態，都屬於混亂狀態（錯誤狀態）。前面出現的兩個主題被同時選中的情況，就屬於這其中的一種混亂狀態。
在前面的具體實現中，程式邏輯已經在盡力將系統狀態限制在8個有序狀態上，但實際執行的時候還是進入了某個混亂狀態，這是為什麼呢？
因為一個具體的工程實現，是要面對非常複雜的工程細節的，幾乎沒有一個邏輯是能夠被完美實現的。也許在某個微小的實現細節上出現了意想不到的情況，也許是持久化的時候沒有正確地運用事務處理，也可能有來自系統外的干擾。
但是，對於這個例子來說，我們其實可以在限制系統狀態方面做得更好。有些同學可能已經看出來了，表示主題“選中”和“未選中”的狀態，其實不應該儲存在每個主題物件中（Theme類），而應該全域性儲存一個當前選中的主題ID，這樣，所有可能的選中狀態就只有8個了。
修改之後的資料結構如下（偽碼）：
/**
* 表示主題皮膚的類定義。
*/
public class Theme {
//該主題的ID
public int themeId;
//該主題的名稱
public String name;
//該主題的圖片地址
public String picture;
//其它描述欄位
......
}
/**
* 各個主題資料。
*/
Theme[] themes = ...;
/**
* 全域性配置：當前選中的主題的ID。
* 初始值是預設主題的ID。
*/
int currentThemeId = getFromLocalStore(DEFAULT_CLASSIC_THEME_ID);複製程式碼顯示邏輯修改後如下（偽碼）：
//輸入引數：
//介面中顯示各個主題的View層控制元件
View[] themeViews;
......
for (int i = 0; i < themeViews.length; i++) {
if (themes[i].themeId == currentThemeId) {
//將第i個主題顯示為選中狀態
displaySelected(themeViews[i]);
}
else {
//將第i個主題顯示為未選中狀態
displayNotSelected(themeViews[i]);
}
}複製程式碼使用者重新設定主題的時候，修改後的選中邏輯如下（偽碼）：
//輸入引數：
//介面中顯示各個主題的View層控制元件
View[] themeViews;
//當前使用者要選擇的新主題的下標
int toSelect;
......
//找到舊的選中主題
int oldSelected = -1;
for (int i = 0; i < themes.length; i++) {
if (themes[i].themeId == currentThemeId) {
oldSelected = i; //找到了
break;
}
}
if (toSelect != oldSelected) {
//修改當前選中主題的全域性配置
currentThemeId = themes[toSelect].themeId;
//將當前選中的主題顯示為選中狀態
displaySelected(themeViews[toSelect]);
if (oldSelected != -1) {
//將舊的選中主題顯示為非選中狀態
displayNotSelected(themeViews[oldSelected]);
}
//最後，將修改後的主題資料持久化下來
saveToLocalStore(currentThemeId);
}複製程式碼這個例子雖然簡單，但卻很好地體現出了軟體系統的熵值的概念。
我們程式設計的過程，實際上就是不斷地向系統輸入規則的過程。通過這些規則，我們將系統的執行狀態限制在那些我們認為正確的狀態上（即有序狀態）。因此，避免系統出現那些不合法的、額外的狀態（即混亂狀態），是我們應該竭力去做的，哪怕那些狀態初看起來是“無害”的。
第二個例子
若干年前，當我們在某開放平臺上開發Web應用的時候，發生過這樣一件事。
我們當時的某位後端工程師，打算在新使用者第一次訪問我們的應用的時候，為使用者建立一份初始資料（UserData結構）。同時，在當前訪問請求中還要向使用者展示這份使用者資料。這樣的話，如果是老使用者來訪問，那麼展示的就是該使用者最新積累的資料；相反，如果來訪的是新使用者的話，那麼展示的就是該使用者剛剛初始化的這份資料。
因此，這位工程師設計並實現瞭如下介面：
UserData createOrGet(long userId);複製程式碼在這個介面的實現中，程式先去資料庫查詢UserData，如果能查到，說明是老使用者了，直接返回該UserData；否則，說明是新使用者，則為其初始化一份UserData，並存入資料庫中，然後返回新建立的這份UserData。
如果這裡的UserData確實是一份很基本的使用者資料，且上述介面的實現編碼得當的話，這裡的做法是沒有什麼大問題的。對於一般的應用來說，使用者基本資料通常在註冊時建立，在登入時查詢。而對於開放平臺的內嵌Web應用來說，第一個訪問請求往往同時帶有註冊和登入的性質，因此將建立和查詢合併在一起是合理的。
但是不久，應用內就出現了另外一些查詢UserData的需求。既然原來已經有一個現成的createOrGet介面了，而且它確實能返回一個UserData物件，所以這位工程師出於“程式碼複用”的考慮，在這些需要查詢UserData的地方呼叫了createOrGet介面。
經過本文前面的討論，我們不難看出這樣做的問題：這種做法無意間讓系統的熵增加了。在本該是查詢的邏輯分支上，程式不得不處理跟建立有關的額外邏輯和狀態，而這些多餘的狀態增加了系統進入混亂的概率。
第三個例子
在這一部分，我們討論一個稍微複雜一點的例子，它跟訊息傳送佇列有關。
假設我們要開發一個IM軟體，就跟微信類似。那麼，它傳送訊息（Message）的時候，不應該只是提交一次網路請求這麼簡單。
- 首先，前後多次傳送訊息的各個請求需要排隊；
- 其次，由於網路環境不好而造成請求失敗時，應該在一定程度上能夠重試請求。
- 第三，請求佇列本身需要持久化，這樣即使軟體重啟，未傳送完的訊息也能夠繼續傳送。
因此，我們需要為傳送訊息建立一個有排隊、重試和本地持久化功能的傳送佇列。
關於持久化，其實除了傳送佇列本身需要本地持久化，使用者輸入和接收到的聊天訊息，也需要本地持久化。當訊息傳送成功後，或者當訊息嘗試多次最終還是失敗之後，該訊息在傳送佇列的持久化儲存裡刪除，但是仍然儲存在聊天訊息的持久化儲存裡。
經過以上分析，我們的傳送訊息的介面（send），實現如下（偽碼）：
public void send(Message message) {
//插入到聊天訊息的持久化儲存裡
appendToMessageLocalStore(message);
//插入到傳送佇列的持久化儲存裡
//注：和前一步的持久化操作應該放到同一個DB事務中操作，
//這裡為了演示方便，省去事務程式碼
appendToMessageSendQueueStore(message);
//在記憶體中排隊或者立即傳送請求（帶重試）
queueingOrRequesting(message);
}複製程式碼其中，表示訊息的類Message，如下定義（偽碼）：
/**
* 表示一個聊天訊息的類定義。
*/
public class Message {
//該訊息的ID
public long messageId;
//該訊息的型別
public int type;
//其它描述欄位
......
}複製程式碼如前所述，當網路環境不好而造成請求失敗時，傳送佇列會嘗試重試請求，但如果連續失敗很多次，最終傳送佇列也只能宣告傳送失敗。這時候，在使用者聊天介面上通常會標記該訊息（比如在訊息旁邊標記一個紅色的歎號）。使用者可以等待網路好轉之後，再次點選該訊息來重新傳送它。
這裡的重新傳送，可以仍然呼叫前面的send介面。但是，由於這個時候訊息已經在持久化儲存中存在了，所以不應該再呼叫appendToMessageLocalStore了。當然，保持send介面不變，我們可以通過一個查詢操作來區分是第一次傳送還是重發。
修改後的send介面的實現如下（偽碼）：
public void send(Message message) {
Message oldMessage = queryFromMessageLocalStore(message.messageId);
if (oldMessage == null) {
//沒有查到有這個訊息，說明是首次傳送
//插入到聊天訊息的持久化儲存裡
appendToMessageLocalStore(message);
}
else {
//查到有這個訊息，說明是重發
//只是修改一下聊天訊息的狀態就可以了
//從失敗狀態修改成正在傳送狀態
modifyMessageStatusInLocalStore(message.messageId, STATUS_SENDING);
}
//插入到傳送佇列的持久化儲存裡
//注：和前面兩步的查詢操作以及插入和修改操作
//應該放到同一個DB事務中操作，
//這裡為了演示方便，省去事務程式碼
appendToMessageSendQueueStore(message);
//在記憶體中排隊或者立即傳送請求（帶重試）
queueingOrRequesting(message);
}複製程式碼但是，如果按照本文前面分析的程式設計的熵增原理來看待的話，這裡對於send的修改使得系統的熵增加了。本來首次傳送和重發這兩種不同的情況，在呼叫send之前是很清楚的，但進入send之後我們卻丟失了這個資訊。因此，我們需要在send的實現裡面再依賴一次查詢的結果來判斷這兩種情況（狀態）。
一個程式執行的過程，本質上是根據每一個條件分支，從邏輯樹的頂端，一層一層地向下，選擇出一條執行路徑，最終到達某個終端葉子節點的過程。程式每進入新的下一層，它對於當前系統狀態的理解就更清晰了一點，也就是它需要處理的狀態數就少了一點。最終到達葉子節點的時候，就意味著對於系統某個具體狀態的確定，從而可以執行對應的操作，把問題解決掉。
而上面對於send的修改，卻造成了程式執行過程中需要處理的狀態數反而增加的情況，也就是熵增加了。
如果想要避免這種熵增現象的出現，我們可以考慮新增一個重發介面（resend），程式碼如下（偽碼）：
public void resend(long messageId) {
Message message = queryFromMessageLocalStore(messageId);
if (message == null) {
//不可能情況，錯誤處理
return;
}
//只是修改一下聊天訊息的狀態就可以了
//從失敗狀態修改成正在傳送狀態
modifyMessageStatusInLocalStore(message.messageId, STATUS_SENDING);
//插入到傳送佇列的持久化儲存裡
//注：和前一步的持久化操作應該放到同一個DB事務中操作，
//這裡為了演示方便，省去事務程式碼
appendToMessageSendQueueStore(message);
//在記憶體中排隊或者立即傳送請求（帶重試）
queueingOrRequesting(message);
}複製程式碼當然，有的同學可能會反駁說，這樣新增一個介面的方式，看起來對介面的統一性有破壞。不管是首次傳送，還是重發，都是傳送，如果呼叫同一個介面，會更簡潔。
沒錯，這裡存在一個取捨的問題。
選擇任何事情都是有代價的。如何選擇，取決於你對於邏輯清晰和介面統一，哪一個更看重。
當然，我個人更喜歡邏輯清晰的方式。
在熵增原理的統治之下，系統的演變體現出了明確的方向性，它總是向著代表混亂無序的多數狀態的方向發展。
我們的程式設計，以及一切有條理的生命活動，都是在同這一終極原理對抗。
更進一步理解，熵增原理所體現的系統演變的方向性，其實正是時間箭頭的方向性。
它表明時間不可逆轉，一切物品，都會隨著時間的推移而逐漸損壞、腐化、衰老，甚至逐漸喪失與周圍環境的界限。
它是時間之神手裡的鐵律。
程式碼也和其它物品一樣，不可避免地隨著時間腐化。
唯一的解決方式，就是耗費我們的智慧，不停地維持下去。有如文明的延續。
除非——
有朝一日，
AI出現。
也許，到那時，我們的世界才能維持低熵永遠運轉下去。
那時的低熵體，也許會像歌者一樣，輕聲吟唱起那首古老的歌謠：
我看到了我的愛戀
我飛到她的身邊
我捧出給她的禮物
那是一小塊凝固的時間
時間上有美麗的條紋
摸起來像淺海的泥一樣柔軟
……
（完）
後記：
本文總共列舉了三個程式設計的實際例子。我之所以選擇它們作為例子，並不是因為它們是最好的例子，而是因為它們相對獨立，也相對容易描述清楚。實際上，在日常的程式設計工作中，那些跟本文主旨有關的、涉及系統狀態表達和維護的取捨、折中和決策，幾乎隨時都在進行，特別是在進行介面設計的時候。只是這其中產生的思考也許大多都是靈光一閃，轉瞬即逝。本文嘗試把這些看似微小的思想聚整合篇，希望能對看到本文的讀者們產生一絲幫助。
其它精選文章：
- 技術的正宗與野路子
- 程式設計師的宇宙時間線
- Android端外推送到底有多煩？
- Android和iOS開發中的非同步處理（一）——開篇
- 用樹型模型管理App數字和紅點提示
- 一張圖讀懂RxJava中的執行緒控制
- 宇宙盡頭的描述符（下）
- Redis內部資料結構詳解(5)——quicklist
- Redis內部資料結構詳解(4)——ziplist
