漫谈优化代码

        最经因为工作需要，开始慢慢的优化系统中的功能模块。其中也有了一些心得体会，写出来以免遗忘。

        优化最开始的就是阅读代码，寻找可优化的地方，一般来说先将spring对于sql的打印表示为show，然后运行模块，看后台打印的sql语句是否有很多条，若有很多条，观察是否有改进的可能，如对于我们系统中的代码，有的地方需要去得到一个树形机构的节点的下面的所有的子节点，此时在表结构中的层级码可以轻松解决，而不必采用十分消耗系统资源的迭代的方式来递归出来。又比如某处根据多个用户的ID来得到用户的组织，此时若直接通过ID得到实体然后得到部门是一个非常耗时的过程，因为执行了多次sql语句，与数据库产生了多次的交互，浪费了大量时间，可以将userId组合起来，再采用select in 的方式，即可以方便的查询出需要的结果，并且节省了大量的时间，自我尝试后，对于280多个userId 而言，此处就节省了大约1.5S左右的时间，是非常可观的。

        除了sql语句的产生之外，在执行查询语句的时候，我们也要注意查询出来的结果。有很多时候，对于只需要一个字段的情况，我们依旧采用查询对象，然后迭代对象来得到属性的方式，有时在计数时也是先查询出list，然后由list.size来得到最终的结果。这是非常不可取的。因为这样会导致数据读入到内存中，极度耗费内存做了无用功，如果一个用户查询产生了一个size为1000的list，那么100个用户就会产生100000个list，很容易导致内存直接挂掉。这再我们进行压力测试时表现的非常明显。

        同样的，在页面端，其实也可以提速。在后台于页面交互的时候，有些同事喜欢在后台拼装好html然后在前台接受，但是在数据量比较大的时候，后台的拼接会导致传递的数据包的增大，而只传递必须的json数据在页面端拼装的话，在数据量越大的情况下优势比较明显，自我尝试过在4800多个用户的情况下，后者比前者在前端处理上快了1S左右。

        优化是个慢工活，更需要我们平日里的积累和注意。希望能通过这次的总结在以后的开发过程中规避掉这些问题。