FutureTask和Callable和Executor在微服务开发中的使用/4/8

　　服务迁移到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并发编程的艺术》