返回 登录
0

Java代码优化总结(1)

阅读1314

学习Java的同学注意了!!!
学习过程中遇到什么问题或者想获取学习资源的话,欢迎加入Java学习交流群,群号码:492139965 我们一起学Java!

写在之前
最近,进行了不少代码的优化的部分。免得以后忘记,在这里分享给大家,希望对大家能有点微不足道的帮助!

正文内容
JSON对象解析的过程中要尽量避免多次解析的情况;如非必要,尽量减少JSON对象的反复解析。

使用Redis或数据库查询时,如果是上下文有逻辑关系的代码,尽量避免反复使用同一查询,原则是:能少查一次就少查一次。查询结果建议都要进行一定的非空或其它异常判断等等。

在进行业务逻辑的计算和IO读写操作时,建议分别使用不同的线程。例如:业务逻辑的计算可以使用CPU密集型线程池;而IO操作可以使用IO型线程。RxJava是一个不错的选择工具,值得尝试!

使用重试逻辑时,不要太暴力。
如下图,Redis有可能会出现超时的情况,这里的业务又比较重要,所以有必要加上重试逻辑,而加的重试逻辑又太过暴力了。

图片描述

这样可能得不到想要的效果,反而会加重Redis的负担,建议加上适当的停顿时间。如下图:

图片描述

查询数据库或Redis等等时,应该尽可能给予返回值,前后代码有先后依赖关系时,应该给予必要的逻辑判断。尽量不要像下面这样,insert进去数据库之后就什么不管了。因为insert操作会可能失败的,一旦这里失败,其它有依赖的地方就会产生问题,代码要尽量能考虑到失败时的处理。

图片描述

应当尽量避免大量Redis Key同时(分毫不差的)失效。Redis是单线程模型的,如果大量对象同时失效,后续的请求可能会频繁出现请求超时的问题。如下图:

图片描述

优化方案是:可以在失效时间的后边加上所能容许的随机时间。如下图:

图片描述

Redis要尽量使用池的方式,应该避免使用直连的方式。直接的方式每次都会建立一次TCP连接,而池的方式可以减少TCP连接次数,减少TCP握手时间,提高响应速度。 如此类推,凡是建立对象比较耗时的地方,都可以适当考虑对象池技术。推荐Common-pool2工具,使用起来较简单,不用自己实现。

如果使用双重检查的方式实现单例时,记得加上volatile关键字。因为由于编译器可能会重排序我们的代码,会导致双重检查的编译结果和源码不一致,多线程调用时也可能会有线程安全问题,而volatile可以帮忙我们避免编译器的重排序。

图片描述

使用volatile时应该注意,该关键字只能保证数据的可见性。只有在状态真正独立于程序内其他内容时才能使用 volatile 。 推荐阅读这篇关于volatile的文章:http://www.ibm.com/developerworks/cn/java/j-jtp06197.html

对于频繁操作Redis时,如果各个操作之间没有先后联系,又不用考虑及时返回的结果,应当尽量使用pipline的方式来提高效率。如下图的使用方式:

图片描述

如下图,可以使用pipline的方式提高效率:

图片描述

pipline能 帮忙我们批量处理命令,一次性返回操作结果,减少TCP交互次数,提高效率。但是,pipline的方式不能过度使用,pipline会把Redis的操作结果缓存到内存中,然后一次性返回给客户端,pipline的方式依赖内存的限制,操作结果集尽量不要过大。

使用Redis的锁机制的时候,应当仔细考虑使用的范围和方式。
如下图,此代码使用key的存在与否和是否为1来保证原子性操作。但是,此代码仍然不能保证多线程安全问题。假如有两个线程A和B,同时进入了isExist的逻辑,而A线程获得CPU的资源较早,处理的速度较快,A线程走完整个方法的逻辑时,B线程仍然在原始位置。此时,B线程才获取CPU资源走下面的逻辑,就会出现数据重复插入的问题。

图片描述

a. 优化的方式是可以把ret=xxx这行代码移到if(!isExist…)上面,而if语句里面的查询等操作也可以提到if的上面,尽可能的减少此原子操作的时间。
b. 也可以使用Redis乐观锁的方式来保证原子性操作。关于Redis乐观锁(CAS)的实现方式,请自行Google!

使用Kafka时,生产者和消费者建议使用批量的方式来提高吞吐量,而批量失败的后果也要进行考虑,批量失败对结果的影响肯定要比单一生产或消费大很多。不是特别建议使用下面的这种方式,虽然程序可以正常跑,但是每次遇到Kafka队列里有大量数据积累时都是加机器的方式解决。其实完全可以从代码角度进行优化,减少机器的使用,提高单机的CPU和内存使用率。

图片描述

使用线程池时要注意选择适当的拒绝策略。
如下图,handle方法是在死循环中被调用的,所以创建Runnable任务的速度是非常快的,优化之前的代码是没有拒绝策略的,也就是使用的默认策略。下图是优化过的代码,之前是没有第一块红色区域的代码的。

图片描述

如下图,从JDK源码中可以看出,线程池处理不了的任务是放在无界队列(LinkedBlockingQueue的size=Integer.MAX_VALUE)中的,而这样就有一个很大的问题。如果消费的速度跟不上,内存中就积累了大量的Task,内存使用率会急速上高。所以为线程池任务的存放选择一个合适的拒绝策略就很有必要了。

图片描述

如本问题的第一张图中的第一块代码,如果发生拒绝,会执行executor.getQueue().put(r); 而put是阻塞式的,会一直等待Queue中有可用空间为止,而被阻塞的线程就是放入Task的线程,也就是调用handle的线程,这样就不会导致Queue无限增大了。

学习Java的同学注意了!!!
学习过程中遇到什么问题或者想获取学习资源的话,欢迎加入Java学习交流群,群号码:492139965 我们一起学Java!

评论