<sdffdsfsdfdfs>sfsfsfsdfsdffds</sdfsDS>Fsd

这个人很懒这个人很懒这个人很懒这个人很懒这个人很懒这个人很懒这个人很懒这个人很懒这个人很懒这个人很懒这个人很懒这个人很懒这个人很懒这个人很懒这个人很懒这个人很懒这个人很懒这个人很懒这个人很懒这个人很懒...

Java代码优化总结

点击上方“程序员大咖”,选择“置顶公众号”

关键时刻,第一时间送达!

640?wxfrom=5&wx_lazy=1

640?wx_fmt=gif&wxfrom=5&wx_lazy=1


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

 

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


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

 

使用重试逻辑时,不要太暴力

 

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


640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1


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


640?wx_fmt=jpeg


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


640?wx_fmt=jpeg


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


640?wx_fmt=jpeg


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


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


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


640?wx_fmt=jpeg


使用volatile时应该注意,该关键字只能保证数据的可见性。只有在状态真正独立于程序内其他内容时才能使用 volatile 。


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


640?wx_fmt=jpeg


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


640?wx_fmt=jpeg


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


使用Redis的锁机制的时候,应当仔细考虑使用的范围和方式。


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


640?wx_fmt=jpeg


1

优化的方式是可以把ret=xxx这行代码移到if(!isExist…)上面,而if语句里面的查询等操作也可以提到if的上面,尽可能的减少此原子操作的时间。


2

也可以使用Redis乐观锁的方式来保证原子性操作。关于Redis乐观锁(CAS)的实现方式,请自行百度、Google等等


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


640?wx_fmt=jpeg


使用线程池时要注意选择适当的拒绝策略。


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


640?wx_fmt=jpeg


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


640?wx_fmt=jpeg


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



640.jpeg

  • 来源:http://mp.weixin.qq.com/s/dTOxZjJr_-UDoCsYs4IWjQ

  • 程序员大咖整理发布,转载请联系作者获得授权

640?wx_fmt=gif

640?【点击成为安卓大神】

阅读更多
上一篇因为太难而被禁用的17道Google面试题
下一篇Python自动生成表情包
想对作者说点什么? 我来说一句

JAVA代码优化.txt

2010年03月21日 8KB 下载

C++代码优化方法总结.rar

2009年04月26日 30KB 下载

没有更多推荐了,返回首页

关闭
关闭