昨天陽光城一新超市開張，去超市晃了一圈，人山人海啊！突然感覺這撫州的消費能力不是一般的強。今天討論乙個問題：佇列，資源競爭和鎖。
「稱重處」一定是最繁忙的，因為「資源獨佔」，如果寫**的時候這個地方是要加鎖的，不然一定會出現多執行緒下的併發問題。所以我一直觀察這「壯烈」的場景。很多人是沒有排隊的，直接擁堵在周圍，這裡我稱之為「
搶占式資源競爭
」。計算機內部對於任務的排程並非採用這種方式，原因很簡單，會導致使用者響應不及時這樣不太好的使用者體驗。簡單的說一下為什麼，以「稱重處」這個場景為例，可能某個人搶了很久，但是他仍然沒有搶到「秤」這樣乙個資源，所以他一直要等待，假設有另外乙個人要等他稱重完，那麼對於等他的這個人而言體驗是很不好的。即使從資源公平來講也是不合理的。這裡基本上誰更蠻橫誰力氣大則更有機會搶到「秤」。所以一定會出現「排隊」的必要性。
排隊的好處不言而喻，計算機裡面所說的「fifo（先進先出）」。這樣盡量的保證了資源競爭的公平性。程式設計師也很多的會出現排隊的場景。很多情況下會有「queue(佇列)」的應用。這裡再說一下cpu的時間片分配。如果知道作業系統的都知道對於cpu而言是並非嚴格的按照排隊的順序進行處理。這裡也是為了解決乙個問題。比如說乙個任務執行時間是半個小時，如果嚴格按照排隊的方式則我執行下乙個程式則需要在半個小時後（ps：另外還有乙個原因，因為本身乙個程式的執行並非都是cpu獨佔的，有可能等待io，請求網路等其他資源）。對於多工場景下肯定是不適合的。所以計算機會引入「
時間片
」的概念。這裡其實最關鍵的是進行「
任務切分
」。這裡再回到超市排隊的這樣乙個場景。小a拿著10袋東西去稱重，假設小a把所以東西稱完作為乙個任務（這裡稱之為任務a）。同樣小b拿著5袋東西去稱重（這裡稱之為任務b）。小a和小b組成乙個多工執行場景。由於稱重處只有一處，也就是相當於乙個「cpu」。這樣的場景處理策略是什麼。
第一種策略是小a和小b進行「搶占」。這樣小a和小b完成的時間是不可控的。比如說稱一袋商品的時間是20ms。在最優的情況下，小a完成的時間200ms。小b是100ms。當然最差的情況下小a是300ms。小b也是300ms。從演算法的角度來講可以說這個時間複雜度是不穩定的。下面的圖是乙個簡化版，只要小a或者小b只要搶到秤就可以把所有的東西稱完。
下面是任務a最優的情況
下面是任務b最優的情況
第二種策略就是簡單的排隊，比如說小a排前面，那麼小a稱完10袋商品花了200ms。那麼再稱小b的商品。這樣稱完小b是100ms，但是小b總的時間是多少？300ms(等待時間200ms)。其實就是上圖中任務a最優的情況。
下面就把這個場景進行複雜化。 這裡增加乙個打包處(打包處是可以並行的，小a和小b打包互不干擾)，每打包乙份商品消耗20ms，這裡假設小a在打包的同時是無法把商品放到稱重處進行稱重的（現實場景中人有兩隻手，本身會有乙個並行的工作，所以即使任務內部也可以進行並行，這裡為了把問題簡化，就不做這種處理）。那麼按照剛才排隊的策略很顯然，小a工作完是需要400ms。小b工作完是600ms。「稱重處」總的算起來是工作了580ms。
這張圖簡單的描述了小a在稱重和打包的同時間時間消耗，這裡可以很清楚的看到稱重處是有大量時間空閒的，b的工作佇列就不在此畫出來了。
上面那種策略有什麼問題？就是在小a或者小b打包的同時稱重處是空閒的，總的算起來其實空閒了280ms。這裡小a打包的同時，稱重處可以為小b進行稱重，這樣下來小a和小b工作完是400ms和220ms。但是最後稱重處並非工作了580ms。而是380ms，節約了200ms的時間。當然這裡跟cpu的時間片有關係嗎？已經有些接近了。cpu為了簡化一些處理，比如說cpu把時間切分成乙個乙個小片然後分配給任務。假設在這裡乙個時間片為20ms是最優的。當然cpu的工作遠沒有這麼簡單，由於任務切換也同樣是需要時間的，這裡所描述的場景並沒有體現這樣點。
下面這張圖中很清楚的看到稱重處消耗的時間是380ms。時間利用率有比較大的提公升，小a任務完成總共是400ms。小b任務完成只需要220ms。
這裡要講的其實是生活各處都會有各種策略運用於計算機的設計中。有些人說藝術**於生活，計算機也是如此。上次在某篇文章中談到「影象記憶」。比如說我到過某個地方，其實在腦海裡會有乙個快照（
snapshot），這樣就記下來了。當然計算機怎麼做這個事情，呵呵，就複雜了，目前來講其實是記住「特徵值」，簡單點講比如說這裡有個星巴克，有多少樓，什麼顏色，朝向等一些重要特徵然後進行比對。當然人其實也是這樣的。真正把所有的資訊記下來是不可能的。
軟體隨想錄
最近閱讀了由阮一峰翻譯的，有程式設計師部落酋長之稱的 joel 撰寫的 軟體隨想錄 精華摘抄如下 就如同所有行業最好的人才一樣，那些優秀的程式設計師是不會出現在招聘市場的。通常優秀的程式設計師在整個職業生涯中，可能會有4次求職。實習生制度創造了輸送優秀人才的管道，但是這個管道比較長，而且一路上損耗很...
專案隨想錄
發現自己不怎麼會起題目了。中午回去還沒走到寢室，就接到劉老師的 說要把程式調通，於是中午吃完飯立馬跑回去，把顯示問題解決了。其實那個無效數字問題是因為在hql語句中使用了cast pw as integer 將字串轉成integer型，可是資料庫中的內容程式設計了字母加數字，自然會轉換失敗了，唉，真...
雜文 隨想錄
這裡是一些隨想。關於名為二氫婦女的使用者本人，希望 ta 能有乙個美好的未來。科學雖然給我們許多驚奇，但也攪壞了我們許多好夢。當登上了月球的那一刻，一切有關月的夢都被現實的蒼涼所破碎了。從那一步邁出起，廣寒宮破碎，輝夜姬亦未曾回到月上，阿爾忒彌斯丟失了金弓與駕月之車，一切有關月的神話於此失去光輝，人...