写在之前
最近，进行了不少代码的优化的部分。免得以后忘记，在这里分享给大家，希望对大家能有点微不足道的帮助！
正文内容
JSON对象解析的过程中要尽量避免多次解析的情况；如非必要，尽量减少JSON对象的反复解析。
使用Redis或数据库查询时，如果是上下文有逻辑关系的代码，尽量避免反复使用同一查询，原则是：能少查一次就少查一次。查询结果建议都要进行一定的非空或其它异常判断等等。
在进行业务逻辑的计算和IO读写操作时，建议分别使用不同的线程。例如：业务逻辑的计算可以使用CPU密集型线程池；而IO操作可以使用IO型线程。RxJava是一个不错的选择工具，值得尝试！
-
使用重试逻辑时，不要太暴力。
如下图，Redis有可能会出现超时的情况，这里的业务又比较重要，所以有必要加上重试逻辑，而加的重试逻辑又太过暴力了。
Paste_Image.png
这样可能得不到想要的效果，反而会加重Redis的负担，建议加上适当的停顿时间。如下图：
-
查询数据库或Redis等等时，应该尽可能给予返回值，前后代码有先后依赖关系时，应该给予必要的逻辑判断。尽量不要像下面这样，insert进去数据库之后就什么不管了。因为insert操作会可能失败的，一旦这里失败，其它有依赖的地方就会产生问题，代码要尽量能考虑到失败时的处理。
Paste_Image.png -
应当尽量避免大量Redis Key同时（分毫不差的）失效。Redis是单线程模型的，如果大量对象同时失效，后续的请求可能会频繁出现请求超时的问题。如下图：
Paste_Image.png
优化方案是：可以在失效时间的后边加上所能容许的随机时间。如下图：
Redis要尽量使用池的方式，应该避免使用直连的方式。直接的方式每次都会建立一次TCP连接，而池的方式可以减少TCP连接次数，减少TCP握手时间，提高响应速度。 如此类推，凡是建立对象比较耗时的地方，都可以适当考虑对象池技术。推荐Common-pool2工具，使用起来较简单，不用自己实现。
-
如果使用双重检查的方式实现单例时，记得加上volatile关键字。因为由于编译器可能会重排序我们的代码，会导致双重检查的编译结果和源码不一致，多线程调用时也可能会有线程安全问题，而volatile可以帮忙我们避免编译器的重排序。
Paste_Image.png
使用volatile时应该注意，该关键字只能保证数据的可见性。只有在状态真正独立于程序内其他内容时才能使用 volatile 。 推荐阅读这篇关于volatile的文章：http://www.ibm.com/developerworks/cn/java/j-jtp06197.html
-
对于频繁操作Redis时，如果各个操作之间没有先后联系，又不用考虑及时返回的结果，应当尽量使用pipline的方式来提高效率。如下图的使用方式：
Paste_Image.png
如下图，可以使用pipline的方式提高效率：
pipline能 帮忙我们批量处理命令，一次性返回操作结果，减少TCP交互次数，提高效率。但是，pipline的方式不能过度使用，pipline会把Redis的操作结果缓存到内存中，然后一次性返回给客户端，pipline的方式依赖内存的限制，操作结果集尽量不要过大。
-
使用Redis的锁机制的时候，应当仔细考虑使用的范围和方式。
如下图，此代码使用key的存在与否和是否为1来保证原子性操作。但是，此代码仍然不能保证多线程安全问题。假如有两个线程A和B，同时进入了isExist的逻辑，而A线程获得CPU的资源较早，处理的速度较快，A线程走完整个方法的逻辑时，B线程仍然在原始位置。此时，B线程才获取CPU资源走下面的逻辑，就会出现数据重复插入的问题。
Paste_Image.png
a. 优化的方式是可以把ret=xxx这行代码移到if(!isExist...)上面，而if语句里面的查询等操作也可以提到if的上面，尽可能的减少此原子操作的时间。
b. 也可以使用Redis乐观锁的方式来保证原子性操作。关于Redis乐观锁（CAS）的实现方式，请自行Google！
-
使用Kafka时，生产者和消费者建议使用批量的方式来提高吞吐量，而批量失败的后果也要进行考虑，批量失败对结果的影响肯定要比单一生产或消费大很多。不是特别建议使用下面的这种方式，虽然程序可以正常跑，但是每次遇到Kafka队列里有大量数据积累时都是加机器的方式解决。其实完全可以从代码角度进行优化，减少机器的使用，提高单机的CPU和内存使用率。
Paste_Image.png -
使用线程池时要注意选择适当的拒绝策略。
如下图，handle方法是在死循环中被调用的，所以创建Runnable任务的速度是非常快的，优化之前的代码是没有拒绝策略的，也就是使用的默认策略。下图是优化过的代码，之前是没有第一块红色区域的代码的。
Paste_Image.png
如下图，从JDK源码中可以看出，线程池处理不了的任务是放在无界队列(LinkedBlockingQueue的size=Integer.MAX_VALUE)中的，而这样就有一个很大的问题。如果消费的速度跟不上，内存中就积累了大量的Task，内存使用率会急速上高。所以为线程池任务的存放选择一个合适的拒绝策略就很有必要了。
如本问题的第一张图中的第一块代码，如果发生拒绝，会执行executor.getQueue().put(r); 而put是阻塞式的，会一直等待Queue中有可用空间为止，而被阻塞的线程就是放入Task的线程，也就是调用handle的线程，这样就不会导致Queue无限增大了。
写在之后
写着写着就中午了，该吃饭了... 下次接着分享... 欢迎批评指正，交流学习！
