同步與事務 -試談"問題的問題"的解決方案

面向對象編程有兩個問題要解決: 一是多線程(注意不是併發), 一是語義環境. 但實際上第一個問題也能夠歸到第二個問題中去一塊兒解決. 由於多線程自己並非真正的問題, 真正的問題自始至終是語義意義上的問題.

要是一件東西語義上沒有問題, 爲何我要去理會它? 爲何我要去解決它?

若是我有三個對象A, B, C. 這三個對象組成個人狀態. 那麼有兩種辦法解決它的數據完整性問題:

1, 同步;

2, 事務.

同步指使用synchronized或者鎖來同步全部對它們的訪問. 可是若是是事務, 它就能夠不一樣步. 由於它會經過緩存的方式解決數據的衝突問題. 最後可能會有些事務失敗, 若是不是選擇徹底可序列化的事務級別的話.

同步是語義相關的. 不是變量相關的. 同步的時候不能只看着機器或者說內存狀態, 你要盯着的是語義狀態. 語義狀態的意思是, 也許原本在代碼上絕不相關的兩個東西, 可是它們在語義上是有聯繫的, 是受彼此約束的, 或者說共同組成另外一個狀態. 這樣子的話, 你的同步就可能 不受線程安全的控制, 會滿天飛, 飛獲得處都是.

這樣子,你怎麼辦?

因此說JAVA的語義層次要儘快提上來. 使用機器是最大的問題. 全部的同步, 鎖根本不可能解決問題, 你要解決語義級的問題, 就必須真的去嘗試解決它. 你變成再怎樣的機器高手, 也沒有用.

問題就是問題. 問題有問題的特徵, 解決它要用問題相關的手段而不是機器相關的手段. 機器相關的手段只能解決機器的問題, 解決不了問題的問題.

設想你有一個徹底的語義系統, 程序寫起來會有多麼輕鬆.

從這個角度講, FP不是一件壞事, 至少他作到了部分意義上的負責. 對程序員負責, 對用戶負責, 對計算負責. 總之它負責了一些東西. 相對於狀態式編程 中的直接把機器丟給客戶, 丟給程序員的作法, 它"要臉"多了.

那些看我博客的人, 大家仍是不要看了. 我建議大家不要看. 我這我的很蠢, 說的話也很蠢, 不像大家那麼高科技. 因此不要丟你的臉, 也不要丟你本身的臉(看一個比本身更差的人的東西, 是否是丟臉啊).

我就歷來只看比我寫得更好的東西. 除非有時候須要抄點東西. 但我敢認可 我抄東西, 我已經看清楚的東西, 我就不肯意花時間去弄來弄去, 我就喜歡直接COPY. 由於我在意的不是作法, 而是方法.

因此你不要看啦, 不再要看啦. 求求你啦!