服務遷移到docker後，性能下降了很多。去查看一些接口的調用時間，發現一個接口調用很慢。我開發自己的業務，沒有太多關注這個問題。然後pull代碼後，看了同事加了批量查詢到接口，使用到了Callable,FutureTask,Executor的類。這個接口先調用了一個遠程服務接口，然後又在for循環中調用了另一個服務接口。確實根據數據量決定調用次數，剛好架構師看用的是測試人員的賬號，有很多數據。
自己調用接口，查看了時間。原來調用時間大概在8000ms，優化後的代碼時間爲2000ms，爲原來的1/4,優化後還是可以的。然後我嘗試使用不同的線程池數量，在4左右，然後性能就沒有什麼明顯進步。然後使用全局的線程池對象，在服務開始就創建，但是性能還是沒有進步。然後我打印每個FutureTask的調用時間，發現十幾個get方法，其時間已過1000ms左右，一個是500ms，其他時間都是0ms，這個很奇怪。說明get方法有些阻塞，這個併發請求效率並不高。
public BoardCallable<Board> implement Callable{ public Board call(){ ... } }
這是在業務中用到FutureTask，代碼還是挺簡單的。但是自己在學習多線程時，就沒有遇到合適的業務，所以通過這個業務自己就學習了一點FutureTask的技術，而不是萬年只會用Runnable接口，以後找工作只是讓人覺得寫了一點業務代碼，什麼都不會的人。
多學習別人的代碼，自己才能進步。
小事：今天架構師說我的接口又報錯了，我一看是一個url的path路徑中有空格，說參數不要傳入特殊字符，然後se讓趕快修改。於是我想不就是url編碼嗎，然後想其他也可能有特殊字符，然後就在RestTemplate中加入UriEdcode代碼。然後就部署一下，沒想到架構師說服務出問題了，我一看，原理來是我畫蛇添足，將整個url都編碼了，然後就看到奇怪的http://10.19.12.21...被編碼成了http%DF...這種奇怪的東西，然後就訪問出錯，導致測試人員無法測試。然後架構師說我沒搞清問題，開發後沒在本地測試。哎，我有口難言，本地測試也還要構造測試用例。這次犯錯還是對url編碼的認識存在半吊子轉態，沒有認識到http://和ip地址的作用。這在任何時候都是這樣傳遞的，是不能轉義的，就像‘/’也是不能轉義的。
參考資料：《java併發編程的藝術》