原创 windows下兩個版本的JDK任意切換
概括總結 2018年9月25日，Java11發佈了。發佈幾天後我就在電腦上裝了一個，一直沒用上。今天想用一下，但是發現修改環境變量挺麻煩的，於是就想寫個工具來自動切換。 前提說明 windows下的不同的用戶可能有不同的權限，因此
2018-10-10 03:56:37
原创 提交訂單性能優化系列之015-收貨地址由根據ID查詢改爲傳參
概括總結 在電商下單時，一般都需要選擇收貨地址。這時候，在頁面顯示的信息已經包含手機號、姓名、詳細地址、地址ID等信息了。那麼這時候可以有兩種選擇，1、只把地址ID作爲參數傳過去，後臺根據ID重新查詢地址對象，對對象中獲取詳細信息；
2018-10-06 03:44:52
2
原创 提交訂單性能優化系列之016-緩存商品
概括總結 這一版測試把商品信息存在內存中，而不是每次都查詢數據庫。結果是：查詢緩存比查詢數據庫的性能好5.28%。 016版本更新說明 Version016NoCache.java：沒有緩存，查數據庫的版本。 Version016
2018-10-06 03:44:52
原创 提交訂單性能優化系列之017-數據庫ID爲int(10)類型與long(20)類型的對比
概括總結 int(10)類型的性能比long(20)類型的性能好4.01%（差別不明顯）。 017版本更新說明 這一版本有兩個SQL文件： Version017IntegerId.sql：其中的ID都是int(10)類型的 Ver
2018-10-06 03:44:52
原创 提交訂單性能優化系列之014-JDBC分別提交改爲一起提交
概括總結 提交訂單時有3個對數據庫有改動的操作，當3個操作一起提交時，比3個操作分別提交的性能要高8.40%。 014版本更新說明 提交訂單時對數據庫有改動的操作有： 第5步：保存訂單到數據庫中，並返回訂單ID 第6步：保存訂單商
2018-10-04 11:01:43
2
原创 提交訂單性能優化系列之013-測試SQL語句中少查詢幾個字段(包括大字段)
概括總結 這一版本寫了兩個測試類，一個測試類中查詢全部字段，另一個測試類中只查詢必要的字段，然後對比性能。結論是：根據是減少的字段的長度不同，性能會不同。具體請查看下面的測試結果。 013版本更新說明 這個版本的改動很簡單，Ver
2018-10-03 03:56:40
2
原创 提交訂單性能優化系列之012-引入FutureTask
概括總結 引入FutureTask能提高併發度，相應就可以提升性能，這次測試的結是，提升了38.93%（參考值）。它的缺點也很明顯，就是增加了代碼的複雜度，不方便閱讀了，且對異常也要額外處理，而且大家對FutureTask也不是很熟
2018-10-02 03:53:49
2
原创 提交訂單性能優化系列之011-放棄java同步，引入數據庫修改行數來驗證庫存【重要】
概括總結 既然Java同步之後，性能這麼差，那麼有沒有辦法可以不使用Java同步呢？有的，那就是利用數據庫修改的行數來驗證庫存。另外，假設現在庫存是10，需要減少1，推薦的做法是update Goods set stock=stoc
2018-10-02 03:53:49
3
原创 提交訂單性能優化系列之010-進一步減小同步代碼塊（中的非關鍵代碼）
概括總結 這一版進一步減小了同步代碼塊，我以爲會有相對明顯一點的進步，但是結果並沒有。 010版本更新說明 爲了減小同步代碼塊，同時方便對比，拆分成了兩個文件：Version010Method1.java、Version010Me
2018-09-30 04:03:53
2
原创 提交訂單性能優化系列之009-對比整個方法同步與方法中的部分代碼同步
概括總結 在用到synchronized關鍵字的時候，憑直覺就會加在方法上，比如public static synchronized void test(){}，但是這種直覺不見得是對的，估計大部分時候是出圖方便，想偷懶，才直接加到
2018-09-30 04:03:53
1
原创 提交訂單性能優化系列之008-對比static方法與非static方法
概括總結 在這個版本中，把提交訂單的方法設置成public static synchronized的，與僅僅是設置public synchronized的，在提交訂單的性能上有什麼差別？答案是：沒有明顯區別（是同樣的差）。 008
2018-09-26 03:47:09
3
原创 提交訂單性能優化系列之007-方法上加上synchronized，性能下降93%
概括總結 在一個public static的方法上加上synchronized關鍵字以後，相當於回到了單線程的狀態，性能直線下降93.61%，一夜回到解放前。 007版本更新說明 在原來的submitOrder方法之上增加了一個s
2018-09-26 03:47:09
原创 提交訂單性能優化系列之006-普通的Thread多線程改爲Java8的parallelStream併發流
概括總結 Java8的parallelStream併發流能達到跟多線程類似的效果，但它也不是什麼善茬，爲了得到跟上一版本的多線程類似的效果，一改再改，雖然最後改出來了，但是還是存在理解不了的地方。 006版本更新說明 上一版本中
2018-09-26 03:47:09
6
原创 提交訂單性能優化系列之005-單線程改爲多線程，測試併發線程數與性能之間的關係
概括總結 “併發線程數量”與“每秒能提交的訂單數量”之間並不是線性的關係，當達到某個臨界值以後，線程的增加對性能的提升就不明顯了，甚至會降低性能。至於“臨界值”是多少，不同的電腦應該是不一樣的。我這次測試的線程臨界值是365左右。
2018-09-21 02:33:43
2
原创 提交訂單性能優化系列之003-測試阿里巴巴的druid數據源
概括總結 使用druid數據源之後，相對於第002版自己隨手寫的數據庫，性能反而下降了8.49%。原因在於，002版是“隨手”寫的，因此功能非常簡陋，要什麼沒什麼，只能從內存中獲取連接，因此很快。而druid數據源是一個工業級別的產品
2018-09-17 03:55:09
3