Map的遍历方式优化。在开发中我见过很多人是这样遍历Map的：先得到keySet()视图，然后遍历keys，通过get(key)的方式来获取对应的value。这种遍历性能其实是很差的，因为我们在遍历keys的时候需要花费一定的时间，在get(key)的时候又会花费一定的时间；我们都知道Map的get()是要计算hashCode然后通过hashCode计算数组的下标，如果有hash冲突又会遍历链表，这种遍历方式显然是低效的，cpu资源是宝贵的这种方式会严重占用cpu并且时间花费的要长得多。
解决方法：通过entrySet()获取key、value视图，一次遍历就可以获取对应的value，而不需要通过get()；不过你也可以用迭代遍历，这都是可以的。
日志打印不规范。比如：LOGGER.info(“请求参数：”+params.toString); 日志是盘查问题的关键信息，所以在一个系统中无处不在，一个线程可能产生的log数量就是成百上千行，如果每条日志都这么打印的话会严重影响整个应用的性能。因为字符串拼接的性能是很差的，相信我们都对String不陌生，像这种String c=a+b的方式性能有多好自己也清楚。
解决方法：LOGGER.info(“请求参数：{}”，params.toString)
没有考虑线程安全问题。如：在多线程系统应用HashMap；线程安全的概念简单来讲就是：同一个代码块在单线程和多线程的执行情况下的结果是一样的，否则线程非安全。如果在多线程系统应用了HashMap可能导致多个线程之间数据混淆或者是严重占用系统资源，占用系统资源即为发生了循环链表的问题，具体为什么产生循环链表这里就不多加阐述了；同时String、StringBuffer、StringBuilder也类似。
解决方法：用HashTable或者ConCurrentHashMap替换HashMap
无效代码。比如：Date date=new Date()，在判断date是否是空的时候用if( date!=null && !"".equal(date))；我们都知道date是Date类型永远也不可能是String类型，但是在写代码的时候我们却又一个习惯喜欢加上"".equal(date)来判断，当然这么写是不会有错的，虽然Date不是Strng但是由于 is-a的原则他们的父类都是Object，而equal是Object的方法所以那样判断自然也没有错。这里讲的不单单是Date这个类型，如果是非String类型都这样；还有就是当我们使用List<String> list=new ArrayList<>的方式的时候，后续用list这个对象的时候不需要判断是否为null，因为new出来的对象在没有被JVM回收之前引用的对象永远是非null。
解决方法：去除无效代码
合理使用同步锁。比如：全局定义了一个private static final DateFormat df=new SimpleDateFormat(“yyyy-MM-dd HH:MM:ss”)变量; 在该类中使用到df对象的时候都应用了同步锁；如果在线程并大量大的时候同步锁会严重占用系统资源的开销，因为获得锁与释放锁的过程都是需要占用资源的同时也会带来并发量的下降，所以在能不用同步锁解决问题的时候尽可能不使用锁，万不得已的时候就可以使用。
解决方法：去除同步锁，在方法中定义局部变量：DateFormat df=new SimpleDateFormat(“yyyy-MM-dd HH:MM:ss”)
Linux公社的RSS地址：https://www.linuxidc.com/rssFeed.aspx