資料庫層面解決
總結一想到多執行緒，併發問題，首先想到sychronized 關鍵字。關於sychronized 的關鍵字又進行了簡單的複習。首先 sychronized 是基於 jvm 的。它有幾種使用方式，分別是修飾**塊，修飾方法，修飾靜態方法，修飾類。在使用上範圍能盡量縮小的就盡量縮小。同時其中需要注意一點的是修飾**塊和修飾方法的話僅是同一物件時起作用，不同物件的話是不起作用的。這裡又延伸出另乙個問題，每次請求時是同乙個物件還是多個物件。這裡我們大家都知道spring 管理的bean 預設是單例的，所以修飾在**塊或者方法上應該不會有什麼問題。實現起來比較簡單，直接在**塊或方法前加sychronized 關鍵字就可以了。
使用sychronized 關鍵字的話實現起來比較簡單，但是在併發效能上不會好，因為同時選擇不同宿舍時由於是使用一段**，同樣是需要等待的。其實我們只是想在選擇同乙個宿舍時才進行加鎖等待。這樣無疑是降低了併發效能。
首先呢，我們使用的是 mysql 資料庫。mysql 資料庫有這麼幾個概念。表鎖，葉鎖，和行鎖。顧名思義，就是在修改表資料時預設給表或行加鎖。加鎖後不再允許其他事物進行修改。mysql 預設是行鎖。大家也可以自己查一下mysql預設的鎖機制。
這裡呢我們使用樂觀鎖的思路，在提交時進行驗證。使用這種思路的話有兩種解決思路。
一是資料庫中加乙個version欄位，每次修改後自動加1，首先我們先查詢出要修改的宿舍資訊，查詢出來之後更新時條件加上查詢時的版本號，如果在這期間有學生選擇了宿舍，版本號加1，則此次更新則失敗。這種方式有乙個弊端，就是說哪怕我的宿舍人數還沒有住滿，只要在操作期間有人入住更新了資料庫資訊，則都是提示失敗了，這種對於使用者來說是不太友好的。
二是在更新宿舍已入住人數時加上條件判斷。條件判斷為已入住人數加1小於宿舍可住總人數就可以了。如果更新失敗則提示使用者宿舍已經住滿就可以了。
最終 綜合考慮使用資料庫預設自帶的鎖機制來解決這麼問題。上述描述中資料庫層面解決的第二種方式。當然整個場景中沒有考慮高併發的問題，每年開學每個學校的新生人數最多就幾千人，所以也不需要考慮負載均衡之類的問題了。這是這個場景我的乙個整體的思路，歡迎小夥伴們批評指正。
測試之新生入學系統，多乙份收穫
整個五月份，除了本身的計算機學習外，還參與了基礎部評教和itoo測試工作。也正是因為這兩項活動，才讓自己真正感受到天天都要開會是個怎麼樣的感受。下面就將這段時間在itoo測試的學習情況總結總結，其中也是學習到了很多自己在計算機學習中學不到的一些東西。其實，最開始的工作只有itoo測試組。等到五月中旬...