用了这18种方案，接口性能从11。3s降为170ms！

　　之前工作中，遇到一个504超时问题。原因是因为接口耗时过长，超过nginx配置的10秒。然后真枪实弹搞了一次接口性能优化，最后接口从11。3s降为170ms。本文将跟小伙伴们分享接口优化的一些通用方案。
　　1。批量思想：批量操作数据库
　　优化前：for循环单笔入库for（TransDetaildetail：transDetailList）｛insert（detail）；｝
　　优化后：batchInsert（transDetailList）；
　　打个比喻：
　　打个比喻：假如你需要搬一万块砖到楼顶，你有一个电梯，电梯一次可以放适量的砖（最多放500），你可以选择一次运送一块砖，也可以一次运送500，你觉得哪种方式更方便，时间消耗更少？2。异步思想：耗时操作，考虑放到异步执行
　　耗时操作，考虑用异步处理，这样可以降低接口耗时。
　　假设一个转账接口，匹配联行号，是同步执行的，但是它的操作耗时有点长，优化前的流程：
　　为了降低接口耗时，更快返回，你可以把匹配联行号移到异步处理，优化后：
　　除了转账这个例子，日常工作中还有很多这种例子。比如：用户注册成功后，短信邮件通知，也是可以异步处理的至于异步的实现方式，你可以用线程池，也可以用消息队列实现。3。空间换时间思想：恰当使用缓存。
　　在适当的业务场景，恰当地使用缓存，是可以大大提高接口性能的。缓存其实就是一种空间换时间的思想，就是你把要查的数据，提前放好到缓存里面，需要时，直接查缓存，而避免去查数据库或者计算的过程。
　　这里的缓存包括：Redis缓存，JVM本地缓存，memcached，或者Map等等。我举个我工作中，一次使用缓存优化的设计吧，比较简单，但是思路很有借鉴的意义。
　　那是一次转账接口的优化，老代码，每次转账，都会根据客户账号，查询数据库，计算匹配联行号。
　　因为每次都查数据库，都计算匹配，比较耗时，所以使用缓存，优化后流程如下：
　　4。预取思想：提前初始化到缓存
　　预取思想很容易理解，就是提前把要计算查询的数据，初始化到缓存。如果你在未来某个时间需要用到某个经过复杂计算的数据，才实时去计算的话，可能耗时比较大。这时候，我们可以采取预取思想，提前把将来可能需要的数据计算好，放到缓存中，等需要的时候，去缓存取就行。这将大幅度提高接口性能。
　　我记得以前在第一个公司做视频直播的时候，看到我们的直播列表就是用到这种优化方案。就是启动个任务，提前把直播用户、积分等相关信息，初始化到缓存。5。池化思想：预分配与循环使用
　　大家应该都记得，我们为什么需要使用线程池？
　　线程池可以帮我们管理线程，避免增加创建线程和销毁线程的资源损耗。
　　如果你每次需要用到线程，都去创建，就会有增加一定的耗时，而线程池可以重复利用线程，避免不必要的耗时。池化技术不仅仅指线程池，很多场景都有池化思想的体现，它的本质就是预分配与循环使用。
　　比如TCP三次握手，大家都很熟悉吧，它为了减少性能损耗，引入了KeepAlive长连接，避免频繁的创建和销毁连接。当然，类似的例子还有很多，如数据库连接池、HttpClient连接池。
　　我们写代码的过程中，学会池化思想，最直接相关的就是使用线程池而不是去new一个线程。6。事件回调思想：拒绝阻塞等待。
　　如果你调用一个系统B的接口，但是它处理业务逻辑，耗时需要10s甚至更多。然后你是一直阻塞等待，直到系统B的下游接口返回，再继续你的下一步操作吗？这样显然不合理。
　　我们参考IO多路复用模型。即我们不用阻塞等待系统B的接口，而是先去做别的操作。等系统B的接口处理完，通过事件回调通知，我们接口收到通知再进行对应的业务操作即可。
　　如果大家忘记了IO模型，可以复习一下我的文章：看一遍就理解：IO模型详解7。远程调用由串行改为并行
　　假设我们设计一个APP首页的接口，它需要查用户信息、需要查banner信息、需要查弹窗信息等等。如果是串行一个一个查，比如查用户信息200ms，查banner信息100ms、查弹窗信息50ms，那一共就耗时350ms了，如果还查其他信息，那耗时就更大了。
　　其实我们可以改为并行调用，即查用户信息、查banner信息、查弹窗信息，可以同时并行发起。
　　最后接口耗时将大大降低。有些小伙伴说，不知道如何使用并行优化接口？
　　我之前写过一篇文章并行优化接口的文章，保姆级别的！大家可以看一下，看完会有用的：后端思维篇，手把手教你写一个并行调用模板8。锁粒度避免过粗
　　在高并发场景，为了防止超卖等情况，我们经常需要加锁来保护共享资源。但是，如果加锁的粒度过粗，是很影响接口性能的。
　　什么是加锁粒度呢？
　　其实就是就是你要锁住的范围是多大。比如你在家上卫生间，你只要锁住卫生间就可以了吧，不需要将整个家都锁起来不让家人进门吧，卫生间就是你的加锁粒度。
　　不管你是synchronized加锁还是redis分布式锁，只需要在共享临界资源加锁即可，不涉及共享资源的，就不必要加锁。这就好像你上卫生间，不用把整个家都锁住，锁住卫生间门就可以了。
　　比如，在业务代码中，有一个ArrayList因为涉及到多线程操作，所以需要加锁操作，假设刚好又有一段比较耗时的操作（代码中的slowNotShare方法）不涉及线程安全问题。反例加锁，就是一锅端，全锁住：不涉及共享资源的慢方法privatevoidslowNotShare（）｛try｛TimeUnit。MILLISECONDS。sleep（100）；｝catch（InterruptedExceptione）｛｝｝错误的加锁方法publicintwrong（）｛longbeginTimeSystem。currentTimeMillis（）；IntStream。rangeClosed（1，10000）。parallel（）。forEach（i｛加锁粒度太粗了，slowNotShare其实不涉及共享资源synchronized（this）｛slowNotShare（）；data。add（i）；｝｝）；log。info（cosumetime：｛｝，System。currentTimeMillis（）beginTime）；returndata。size（）；｝复制代码
　　正例：publicintright（）｛longbeginTimeSystem。currentTimeMillis（）；IntStream。rangeClosed（1，10000）。parallel（）。forEach（i｛slowNotShare（）；可以不加锁只对List这部分加锁synchronized（data）｛data。add（i）；｝｝）；log。info（cosumetime：｛｝，System。currentTimeMillis（）beginTime）；returndata。size（）；｝复制代码9。切换存储方式：文件中转暂存数据
　　如果数据太大，落地数据库实在是慢的话，就可以考虑先用文件的方式暂存。先保存文件，再异步下载文件，慢慢保存到数据库。
　　这里可能会有点抽象，给大家分享一个，我之前的一个真实的优化案例吧。
　　之前开发了一个转账接口。如果是并发开启，10个并发度，每个批次1000笔转账明细数据，数据库插入会特别耗时，大概6秒左右；这个跟我们公司的数据库同步机制有关，并发情况下，因为优先保证同步，所以并行的插入变成串行啦，就很耗时。
　　优化前，1000笔明细转账数据，先落地DB数据库，返回处理中给用户，再异步转账。如图：
　　记得当时压测的时候，高并发情况，这1000笔明细入库，耗时都比较大。所以我转换了一下思路，把批量的明细转账记录保存的文件服务器，然后记录一笔转账总记录到数据库即可。接着异步再把明细下载下来，进行转账和明细入库。最后优化后，性能提升了十几倍。
　　优化后，流程图如下：
　　如果你的接口耗时瓶颈就在数据库插入操作这里，用来批量操作等，还是效果还不理想，就可以考虑用文件或者MQ等暂存。有时候批量数据放到文件，会比插入数据库效率更高。10。索引
　　提到接口优化，很多小伙伴都会想到添加索引。没错，添加索引是成本最小的优化，而且一般优化效果都很不错。
　　索引优化这块的话，一般从这几个维度去思考：你的SQL加索引了没？你的索引是否真的生效？你的索引建立是否合理？10。1SQL没加索引
　　我们开发的时候，容易疏忽而忘记给SQL添加索引。所以我们在写完SQL的时候，就顺手查看一下explain执行计划。explainselectfromuserinfowhereuserIdlike123；复制代码
　　你也可以通过命令showcreatetable，整张表的索引情况。showcreatetableuserinfo；复制代码
　　如果某个表忘记添加某个索引，可以通过altertableaddindex命令添加索引altertableuserinfoaddindexidxname（name）；复制代码
　　一般就是：SQL的where条件的字段，或者是orderby、groupby后面的字段需需要添加索引。10。2索引不生效
　　有时候，即使你添加了索引，但是索引会失效的。田螺哥整理了索引失效的常见原因：
　　10。3索引设计不合理
　　我们的索引不是越多越好，需要合理设计。比如：删除冗余和重复索引。索引一般不能超过5个索引不适合建在有大量重复数据的字段上、如性别字段适当使用覆盖索引如果需要使用forceindex强制走某个索引，那就需要思考你的索引设计是否真的合理了11。优化SQL
　　处了索引优化，其实SQL还有很多其他有优化的空间。比如这些：
　　更详细的内容，大家可以看我之前的这两篇文章哈：盘点MySQL慢查询的12个原因后端程序员必备：书写高质量SQL的30条建议12。避免大事务问题
　　为了保证数据库数据的一致性，在涉及到多个数据库修改操作时，我们经常需要用到事务。而使用spring声明式事务，又非常简单，只需要用一个注解就行Transactional，如下面的例子：TransactionalpublicintcreateUser（Useruser）｛保存用户信息userDao。save（user）；passCertDao。updateFlag（user。getPassId（））；returnuser。getUserId（）；｝复制代码
　　这块代码主要逻辑就是创建个用户，然后更新一个通行证pass的标记。如果现在新增一个需求，创建完用户，调用远程接口发送一个email消息通知，很多小伙伴会这么写：TransactionalpublicintcreateUser（Useruser）｛保存用户信息userDao。save（user）；passCertDao。updateFlag（user。getPassId（））；sendEmailRpc（user。getEmail（））；returnuser。getUserId（）；｝复制代码
　　这样实现可能会有坑，事务中嵌套RPC远程调用，即事务嵌套了一些非DB操作。如果这些非DB操作耗时比较大的话，可能会出现大事务问题。
　　所谓大事务问题就是，就是运行时间长的事务。由于事务一致不提交，就会导致数据库连接被占用，即并发场景下，数据库连接池被占满，影响到别的请求访问数据库，影响别的接口性能。
　　大事务引发的问题主要有：接口超时、死锁、主从延迟等等。因此，为了优化接口，我们要规避大事务问题。我们可以通过这些方案来规避大事务：RPC远程调用不要放到事务里面一些查询相关的操作，尽量放到事务之外事务中避免处理太多数据13。深分页问题
　　在以前公司分析过几个接口耗时长的问题，最终结论都是因为深分页问题。
　　深分页问题，为什么会慢？我们看下这个SQLselectid，name，balancefromaccountwherecreatetime20200919limit100000，10；复制代码
　　limit100000，10意味着会扫描100010行，丢弃掉前100000行，最后返回10行。即使createtime，也会回表很多次。
　　我们可以通过标签记录法和延迟关联法来优化深分页问题。13。1标签记录法
　　就是标记一下上次查询到哪一条了，下次再来查的时候，从该条开始往下扫描。就好像看书一样，上次看到哪里了，你就折叠一下或者夹个书签，下次来看的时候，直接就翻到啦。
　　假设上一次记录到100000，则SQL可以修改为：selectid，name，balanceFROMaccountwhereid100000limit10；复制代码
　　这样的话，后面无论翻多少页，性能都会不错的，因为命中了id主键索引。但是这种方式有局限性：需要一种类似连续自增的字段。13。2延迟关联法
　　延迟关联法，就是把条件转移到主键索引树，然后减少回表。优化后的SQL如下：selectacct1。id，acct1。name，acct1。balanceFROMaccountacct1INNERJOIN（SELECTa。idFROMaccountaWHEREa。createtime20200919limit100000，10）ASacct2onacct1。idacct2。id；复制代码
　　优化思路就是，先通过idxcreatetime二级索引树查询到满足条件的主键ID，再与原表通过主键ID内连接，这样后面直接走了主键索引了，同时也减少了回表。14。优化程序结构
　　优化程序逻辑、程序代码，是可以节省耗时的。比如，你的程序创建多不必要的对象、或者程序逻辑混乱，多次重复查数据库、又或者你的实现逻辑算法不是最高效的，等等。
　　我举个简单的例子：复杂的逻辑条件，有时候调整一下顺序，就能让你的程序更加高效。
　　假设业务需求是这样：如果用户是会员，第一次登陆时，需要发一条感谢短信。如果没有经过思考，代码直接这样写了if（isUserVipisFirstLogin）｛sendSmsMsg（）；｝复制代码
　　假设有5个请求过来，isUserVip判断通过的有3个请求，isFirstLogin通过的只有1个请求。那么以上代码，isUserVip执行的次数为5次，isFirstLogin执行的次数也是3次，如下：
　　如果调整一下isUserVip和isFirstLogin的顺序：if（isFirstLoginisUserVip）｛sendMsg（）；｝复制代码
　　isFirstLogin执行的次数是5次，isUserVip执行的次数是1次：
　　酱紫程序是不是变得更高效了呢？15。压缩传输内容
　　压缩传输内容，传输报文变得更小，因此传输会更快啦。10M带宽，传输10k的报文，一般比传输1M的会快呀。
　　打个比喻，一匹千里马，它驮着100斤的货跑得快，还是驮着10斤的货物跑得快呢？
　　再举个视频网站的例子：
　　如果不对视频做任何压缩编码，因为带宽又是有限的。巨大的数据量在网络传输的耗时会比编码压缩后，慢好多倍。16。海量数据处理，考虑NoSQL
　　之前看过几个慢SQL，都是跟深分页问题有关的。发现用来标签记录法和延迟关联法，效果不是很明显，原因是要统计和模糊搜索，并且统计的数据是真的大。最后跟组长对齐方案，就把数据同步到Elasticsearch，然后这些模糊搜索需求，都走Elasticsearch去查询了。
　　我想表达的就是，如果数据量过大，一定要用关系型数据库存储的话，就可以分库分表。但是有时候，我们也可以使用NoSQL，如Elasticsearch、Hbase等。17。线程池设计要合理
　　我们使用线程池，就是让任务并行处理，更高效地完成任务。但是有时候，如果线程池设计不合理，接口执行效率则不太理想。
　　一般我们需要关注线程池的这几个参数：核心线程、最大线程数量、阻塞队列。如果核心线程过小，则达不到很好的并行效果。如果阻塞队列不合理，不仅仅是阻塞的问题，甚至可能会OOM如果线程池不区分业务隔离，有可能核心业务被边缘业务拖垮。
　　大家可以看下我之前两篇有关于线程池的文章：细数线程池的10个坑面试必备：Java线程池解析18。机器问题（fullGC、线程打满、太多IO资源没关闭等等）。
　　有时候，我们的接口慢，就是机器处理问题。主要有fullGC、线程打满、太多IO资源没关闭等等。之前排查过一个fullGC问题：运营小姐姐导出60多万的excel的时候，说卡死了，接着我们就收到监控告警。后面排查得出，我们老代码是ApachePOI生成的excel，导出excel数据量很大时，当时JVM内存吃紧会直接FullGC了。如果线程打满了，也会导致接口都在等待了。所以。如果是高并发场景，我们需要接入限流，把多余的请求拒绝掉。如果IO资源没关闭，也会导致耗时增加。这个大家可以看下，平时你的电脑一直打开很多很多文件，是不是会觉得很卡。（三）Java性能优化的55个细节1。尽量在合适的场合使用单例
　　使用单例可以减轻加载的负担，缩短加载的时间，提高加载的效率，但并不是所有地方都适用于单例，简单来说，单例主要适用于以下三个方面：
　　第一，控制资源的使用，通过线程同步来控制资源的并发访问；
　　第二，控制实例的产生，以达到节约资源的目的；
　　第三，控制数据共享，在不建立直接关联的条件下，让多个不相关的进程或线程之间实现通信。2。尽量避免随意使用静态变量
　　要知道，当某个对象被定义为static变量所引用，那么GC通常是不会回收这个对象所占有的内存，如publicclassA｛privatestaticBbnewB（）；｝
　　此时静态变量b的生命周期与A类同步，如果A类不会卸载，那么b对象会常驻内存，直到程序终止。3。尽量避免过多过常的创建Java对象
　　尽量避免在经常调用的方法，循环中new对象，由于系统不仅要花费时间来创建对象，而且还要花时间对这些对象进行垃圾回收和处理，在我们可以控制的范围内，最大限度的重用对象，最好能用基本的数据类型或数组来替代对象。4。尽量使用final修饰符
　　带有final修饰符的类是不可派生的。在JAVA核心API中，有许多应用final的例子，例如java。lang。String，为String类指定final防止了使用者覆盖length（）方法。另外，如果一个类是final的，则该类所有方法都是final的。java编译器会寻找机会内联（inline）所有的final方法（这和具体的编译器实现有关）。此举能够使性能平均提高50。
　　如：让访问实例内变量的gettersetter方法变成final：
　　简单的gettersetter方法应该被置成final，这会告诉编译器，这个方法不会被重载，所以，可以变成inlined，例子：classMAF｛publicvoidsetSize（intsize）｛sizesize；｝privateintsize；｝更正classDAFfixed｛finalpublicvoidsetSize（intsize）｛sizesize；｝privateintsize；｝5。尽量使用局部变量
　　调用方法时传递的参数以及在调用中创建的临时变量都保存在栈（Stack）中，速度较快。其他变量，如静态变量，实例变量等，都在堆（Heap）中创建，速度较慢。6。尽量处理好包装类型和基本类型两者的使用场所
　　虽然包装类型和基本类型在使用过程中是可以相互转换，但它们两者所产生的内存区域是完全不同的，基本类型数据产生和处理都在栈中处理，包装类型是对象，是在堆中产生实例。在集合类对象，有对象方面需要的处理适用包装类型，其他的处理提倡使用基本类型。7。慎用synchronized，尽量减小synchronize的方法
　　都知道，实现同步是要很大的系统开销作为代价的，甚至可能造成死锁，所以尽量避免无谓的同步控制。synchronize方法被调用时，直接会把当前对象锁了，在方法执行完之前其他线程无法调用当前对象的其他方法。所以synchronize的方法尽量小，并且应尽量使用方法同步代替代码块同步。9。尽量不要使用finalize方法
　　实际上，将资源清理放在finalize方法中完成是非常不好的选择，由于GC的工作量很大，尤其是回收Young代内存时，大都会引起应用程序暂停，所以再选择使用finalize方法进行资源清理，会导致GC负担更大，程序运行效率更差。10。尽量使用基本数据类型代替对象
　　Stringstrhello；
　　上面这种方式会创建一个hello字符串，而且JVM的字符缓存池还会缓存这个字符串；
　　StringstrnewString（hello）；
　　此时程序除创建字符串外，str所引用的String对象底层还包含一个char〔〕数组，这个char〔〕数组依次存放了h，e，l，l，o11。多线程在未发生线程安全前提下应尽量使用HashMap、ArrayList
　　HashTable、Vector等使用了同步机制，降低了性能。12。尽量合理的创建HashMap
　　当你要创建一个比较大的hashMap时，充分利用这个构造函数publicHashMap（intinitialCapacity，floatloadFactor）；
　　避免HashMap多次进行了hash重构，扩容是一件很耗费性能的事，在默认中initialCapacity只有16，而loadFactor是0。75，需要多大的容量，你最好能准确的估计你所需要的最佳大小，同样的Hashtable，Vectors也是一样的道理。13。尽量减少对变量的重复计算
　　如：for（inti0；ilist。size（）；i）
　　应该改为for（inti0，lenlist。size（）；ilen；i）
　　并且在循环中应该避免使用复杂的表达式，在循环中，循环条件会被反复计算，如果不使用复杂表达式，而使循环条件值不变的话，程序将会运行的更快。14。尽量避免不必要的创建
　　如：AanewA（）；if（i1）｛list。add（a）；｝
　　应该改为if（i1）｛AanewA（）；list。add（a）；｝15。尽量在finally块中释放资源
　　程序中使用到的资源应当被释放，以避免资源泄漏。这最好在finally块中去做。不管程序执行的结果如何，finally块总是会执行的，以确保资源的正确关闭。16。尽量使用移位来代替ab的操作
　　是一个代价很高的操作，使用移位的操作将会更快和更有效
　　如intnuma4；intnuma8；
　　应该改为intnuma2；intnuma3；
　　但注意的是使用移位应添加注释，因为移位操作不直观，比较难理解17。尽量使用移位来代替ab的操作
　　同样的，对于操作，使用移位的操作将会更快和更有效
　　如intnuma4；intnuma8；
　　应该改为intnuma2；intnuma3；18。尽量确定StringBuffer的容量
　　StringBuffer的构造器会创建一个默认大小（通常是16）的字符数组。在使用中，如果超出这个大小，就会重新分配内存，创建一个更大的数组，并将原先的数组复制过来，再丢弃旧的数组。在大多数情况下，你可以在创建StringBuffer的时候指定大小，这样就避免了在容量不够的时候自动增长，以提高性能。
　　如：StringBufferbuffernewStringBuffer（1000）；19。尽量早释放无用对象的引用
　　大部分时，方法局部引用变量所引用的对象会随着方法结束而变成垃圾，因此，大部分时候程序无需将局部，引用变量显式设为null。
　　例如：
　　Java代码Publicvoidtest（）｛ObjectobjnewObject（）；Objnull；｝
　　上面这个就没必要了，随着方法test（）的执行完成，程序中obj引用变量的作用域就结束了。但是如果是改成下面：
　　Java代码Publicvoidtest（）｛ObjectobjnewObject（）；Objnull；执行耗时，耗内存操作；或调用耗时，耗内存的方法｝
　　这时候就有必要将obj赋值为null，可以尽早的释放对Object对象的引用。20。尽量避免使用二维数组
　　二维数据占用的内存空间比一维数组多得多，大概10倍以上。21。尽量避免使用split
　　除非是必须的，否则应该避免使用split，split由于支持正则表达式，所以效率比较低，如果是频繁的几十，几百万的调用将会耗费大量资源，如果确实需要频繁的调用split，可以考虑使用apache的StringUtils。split（string，char），频繁split的可以缓存结果。22。ArrayListLinkedList
　　一个是线性表，一个是链表，一句话，随机查询尽量使用ArrayList，ArrayList优于LinkedList，LinkedList还要移动指针，添加删除的操作LinkedList优于ArrayList，ArrayList还要移动数据，不过这是理论性分析，事实未必如此，重要的是理解好2者得数据结构，对症下药。23。尽量使用System。arraycopy（）代替通过来循环复制数组
　　System。arraycopy（）要比通过循环来复制数组快的多24。尽量缓存经常使用的对象
　　尽可能将经常使用的对象进行缓存，可以使用数组，或HashMap的容器来进行缓存，但这种方式可能导致系统占用过多的缓存，性能下降，推荐可以使用一些第三方的开源工具，如EhCache，Oscache进行缓存，他们基本都实现了FIFOFLU等缓存算法。25。尽量避免非常大的内存分配
　　有时候问题不是由当时的堆状态造成的，而是因为分配失败造成的。分配的内存块都必须是连续的，而随着堆越来越满，找到较大的连续块越来越困难。26。慎用异常
　　当创建一个异常时，需要收集一个栈跟踪（stacktrack），这个栈跟踪用于描述异常是在何处创建的。构建这些栈跟踪时需要为运行时栈做一份快照，正是这一部分开销很大。当需要创建一个Exception时，JVM不得不说：先别动，我想就您现在的样子存一份快照，所以暂时停止入栈和出栈操作。栈跟踪不只包含运行时栈中的一两个元素，而是包含这个栈中的每一个元素。
　　如果您创建一个Exception，就得付出代价。好在捕获异常开销不大，因此可以使用trycatch将核心内容包起来。从技术上讲，您甚至可以随意地抛出异常，而不用花费很大的代价。招致性能损失的并不是throw操作尽管在没有预先创建异常的情况下就抛出异常是有点不寻常。真正要花代价的是创建异常。幸运的是，好的编程习惯已教会我们，不应该不管三七二十一就抛出异常。异常是为异常的情况而设计的，使用时也应该牢记这一原则。27。尽量重用对象
　　特别是String对象的使用中，出现字符串连接情况时应使用StringBuffer代替，由于系统不仅要花时间生成对象，以后可能还需要花时间对这些对象进行垃圾回收和处理。因此生成过多的对象将会给程序的性能带来很大的影响。28。不要重复初始化变量
　　默认情况下，调用类的构造函数时，java会把变量初始化成确定的值，所有的对象被设置成null，整数变量设置成0，float和double变量设置成0。0，逻辑值设置成false。当一个类从另一个类派生时，这一点尤其应该注意，因为用new关键字创建一个对象时，构造函数链中的所有构造函数都会被自动调用。这里有个注意，给成员变量设置初始值但需要调用其他方法的时候，最好放在一个方法比如initXXX（）中，因为直接调用某方法赋值可能会因为类尚未初始化而抛空指针异常，如：publicintstatethis。getState（）；29。在javaOracle的应用系统开发中，java中内嵌的SQL语言应尽量使用大写形式，以减少Oracle解析器的解析负担。30。在java编程过程中，进行数据库连接，IO流操作，在使用完毕后，及时关闭以释放资源。因为对这些大对象的操作会造成系统大的开销。31。过分的创建对象会消耗系统的大量内存，严重时，会导致内存泄漏，因此，保证过期的对象的及时回收具有重要意义。JVM的GC并非十分智能，因此建议在对象使用完毕后，手动设置成null。32。在使用同步机制时，应尽量使用方法同步代替代码块同步。33。不要在循环中使用TryCatch语句，应把TryCatch放在循环最外层
　　Error是获取系统错误的类，或者说是虚拟机错误的类。不是所有的错误Exception都能获取到的，虚拟机报错Exception就获取不到，必须用Error获取。34。通过StringBuffer的构造函数来设定他的初始化容量，可以明显提升性能
　　StringBuffer的默认容量为16，当StringBuffer的容量达到最大容量时，她会将自身容量增加到当前的2倍2，也就是2n2。无论何时，只要StringBuffer到达她的最大容量，她就不得不创建一个新的对象数组，然后复制旧的对象数组，这会浪费很多时间。所以给StringBuffer设置一个合理的初始化容量值，是很有必要的！35。合理使用java。util。Vector
　　Vector与StringBuffer类似，每次扩展容量时，所有现有元素都要赋值到新的存储空间中。Vector的默认存储能力为10个元素，扩容加倍。vector。add（index，obj）这个方法可以将元素obj插入到index位置，但index以及之后的元素依次都要向下移动一个位置（将其索引加1）。除非必要，否则对性能不利。同样规则适用于remove（intindex）方法，移除此向量中指定位置的元素。将所有后续元素左移（将其索引减1）。返回此向量中移除的元素。所以删除vector最后一个元素要比删除第1个元素开销低很多。删除所有元素最好用removeAllElements（）方法。如果要删除vector里的一个元素可以使用vector。remove（obj）；而不必自己检索元素位置，再删除，如intindexindexOf（obj）；vector。remove（index）；38。不用new关键字创建对象的实例
　　用new关键词创建类的实例时，构造函数链中的所有构造函数都会被自动调用。但如果一个对象实现了Cloneable接口，我们可以调用她的clone（）方法。clone（）方法不会调用任何类构造函数。下面是Factory模式的一个典型实现：publicstaticCreditgetNewCredit（）｛returnnewCredit（）；｝
　　改进后的代码使用clone（）方法：privatestaticCreditBaseCreditnewCredit（）；publicstaticCreditgetNewCredit（）｛return（Credit）BaseCredit。clone（）；｝39。不要将数组声明为：publicstaticfinal40。HaspMap的遍历：MapString，String〔〕paraMapnewHashMapString，String〔〕（）；for（EntryString，String〔〕entry：paraMap。entrySet（））｛StringappFieldDefIdentry。getKey（）；String〔〕valuesentry。getValue（）；｝
　　利用散列值取出相应的Entry做比较得到结果，取得entry的值之后直接取key和value。41。array（数组）和ArrayList的使用
　　array数组效率最高，但容量固定，无法动态改变，ArrayList容量可以动态增长，但牺牲了效率。42。单线程应尽量使用HashMap，ArrayList，除非必要，否则不推荐使用HashTable，Vector，她们使用了同步机制，而降低了性能。43。StringBuffer，StringBuilder的区别在于：java。lang。StringBuffer线程安全的可变字符序列。一个类似于String的字符串缓冲区，但不能修改。StringBuilder与该类相比，通常应该优先使用StringBuilder类，因为她支持所有相同的操作，但由于她不执行同步，所以速度更快。为了获得更好的性能，在构造StringBuffer或StringBuilder时应尽量指定她的容量。当然如果不超过16个字符时就不用了。相同情况下，使用StringBuilder比使用StringBuffer仅能获得1015的性能提升，但却要冒多线程不安全的风险。综合考虑还是建议使用StringBuffer。44。尽量使用基本数据类型代替对象。45。使用具体类比使用接口效率高，但结构弹性降低了，但现代IDE都可以解决这个问题。46。考虑使用静态方法，如果你没有必要去访问对象的外部，那么就使你的方法成为静态方法。她会被更快地调用，因为她不需要一个虚拟函数导向表。这同事也是一个很好的实践，因为她告诉你如何区分方法的性质，调用这个方法不会改变对象的状态。47。应尽可能避免使用内在的GET，SET方法。48。避免枚举，浮点数的使用。以下举几个实用优化的例子：一、避免在循环条件中使用复杂表达式
　　在不做编译优化的情况下，在循环中，循环条件会被反复计算，如果不使用复杂表达式，而使循环条件值不变的话，程序将会运行的更快。例子：importjava。util。Vector；classCEL｛voidmethod（Vectorvector）｛for（inti0；ivector。size（）；i）Violation；。。。｝｝
　　更正：classCELfixed｛voidmethod（Vectorvector）｛intsizevector。size（）for（inti0；isize；i）；。。。｝｝二、为Vectors和Hashtables定义初始大小
　　JVM为Vector扩充大小的时候需要重新创建一个更大的数组，将原原先数组中的内容复制过来，最后，原先的数组再被回收。可见Vector容量的扩大是一个颇费时间的事。
　　通常，默认的10个元素大小是不够的。你最好能准确的估计你所需要的最佳大小。例子：importjava。util。Vector；publicclassDIC｛publicvoidaddObjects（Object〔〕o）｛iflength10，Vectorneedstoexpandfor（inti0；io。length；i）｛v。add（o）；capacitybeforeitcanaddmoreelements。｝｝publicVectorvnewVector（）；noinitialCapacity。｝
　　更正：
　　自己设定初始大小。
　　publicVectorvnewVector（20）；publicHashtablehashnewHashtable（10）；三、在finally块中关闭Stream
　　程序中使用到的资源应当被释放，以避免资源泄漏。这最好在finally块中去做。不管程序执行的结果如何，finally块总是会执行的，以确保资源的正确关闭。四、使用System。arraycopy（）代替通过来循环复制数组，例子：publicclassIRB｛voidmethod（）｛int〔〕array1newint〔100〕；for（inti0；iarray1。length；i）｛array1〔i〕i；｝int〔〕array2newint〔100〕；for（inti0；iarray2。length；i）｛array2〔i〕array1〔i〕；Violation｝｝｝
　　更正：publicclassIRB｛voidmethod（）｛int〔〕array1newint〔100〕；for（inti0；iarray1。length；i）｛array1〔i〕i；｝int〔〕array2newint〔100〕；System。arraycopy（array1，0，array2，0，100）；｝｝五、让访问实例内变量的gettersetter方法变成final
　　简单的gettersetter方法应该被置成final，这会告诉编译器，这个方法不会被重载，所以，可以变成inlined，例子：classMAF｛publicvoidsetSize（intsize）｛sizesize；｝privateintsize；｝
　　更正：classDAFfixed｛finalpublicvoidsetSize（intsize）｛sizesize；｝privateintsize；｝六、对于常量字符串，用String代替StringBuffer
　　常量字符串并不需要动态改变长度。
　　例子：publicclassUSC｛Stringmethod（）｛StringBuffersnewStringBuffer（Hello）；StringtsWorld！；returnt；｝｝
　　更正：把StringBuffer换成String，如果确定这个String不会再变的话，这将会减少运行开销提高性能。七、在字符串相加的时候，使用代替，如果该字符串只有一个字符的话
　　例子：publicclassSTR｛publicvoidmethod（Strings）｛Stringstringsdviolation。stringabcdviolation。｝｝
　　更正：
　　将一个字符的字符串替换成publicclassSTR｛publicvoidmethod（Strings）｛Stringstringsdstringabcd｝｝
　　以上仅是Java方面编程时的性能优化，性能优化大部分都是在时间、效率、代码结构层次等方面的权衡，各有利弊，不要把上面内容当成教条，或许有些对我们实际工作适用，有些不适用，还望根据实际工作场景进行取舍吧，活学活用，变通为宜。四、最后
　　我相信很多接口的效率问题不是一朝一夕形成的，在需求迭代的过程中，为了需求快速上线，采取直接累加代码的方式去实现功能，这样会造成以上这些接口性能问题。
　　变换思路，更高一级思考问题，站在接口设计者的角度去开发需求，会避免很多这样的问题，也是降本增效的一种行之有效的方式。
　　以上，共勉！