目录
一、系统框架的选择
二、程序优化
表单压缩
局部刷新
仅取所需
逻辑清晰
谨慎继承
程序算法优化
批处理
延迟加载
防止内存泄漏
减少大对象引用
防止争用死锁
存储过程
内存分配
并行
异步
缓存
单机优化顾名思义就是我们要在单机上对系统的性能进行调优。不管你的应用使用的什么框架，什么技术，性能都会显现在对系统软硬件资源的需求上。程序问题可能是前端，也可能是后端，通过单机性能调优，降低了问题的复杂度更有利于解决问题。
程序调优是治本的手段，当前的性能测试往往在集成测试以后进行，性能问题暴漏的太晚，这个时候去修改代码风险很大。我们需要考虑关联业务的相互影响，因此我们要重新进行集成测试，性能回归测试等一长串的测试工作。这势必会增加项目的周期，时间成本是个不能回避的问题，尤其是敏捷开发，系统实时性很强。诸多的不确定性导致了我们不敢，不能，不提倡去做“伤筋动骨”程序调整，只能局限在小范围之内。
这样做导致的结果往往就是随着对问题的深入研究，发现需要做许多调整，甚至可能推翻先前的设计，以及对业务实现的改动，这就很费事，由此可见，性能测试需要提前规划，先架构，后程序优化。（先整体后个体）
一、系统框架的选择
SSH（Struts/Spring MVC,Spring,Hibernate）架构是当前最为流行的MVC模型。SSH架构为我们提供了明晰的层次结构，各层协同完成业务实现，简化了程序的设计过程，加快了程序交付进程。架构丰富的组件虽然给我们带来了便利，但是也有它的短板。
例如，对于大型的业务系统，特别是大数据量的分析计算过程，我们如果把大量的数据从数据库取出后利用应用程序（Java）来进行分析计算，势必会增加网络的传输，而且在程序中进行处理并不是最佳实践。如果换成在数据库中进行处理，我们可以进行连接查询，批处理等操作，不断减少网络的传输，性能也会得到提升。因此我们不能为了遵循架构，为了开发方便而微架构论，应该根据不同的应用场景选择更合适的处理方式。
二、程序优化
低效代码优化，这里说的低效代码排除上边说到的架构问题，纯粹是程序逻辑及算法低效，例如逻辑混乱，调用继承不合理，内存泄漏等。常用的解决方法如下。
表单压缩
压缩表单，减少网络的传输量，以达到提高响应速度的效果。
局部刷新
页面中采取局部获取的方式，减少向服务器的请求，服务器由于负载小就能更快地响应客户的请求，客户的体验也会更好。
仅取所需
只向服务器请求必要的内容，并只向客户端发送必要的表单内容，以减少网络传输，减轻服务器负担。
逻辑清晰
程序逻辑清晰，方便维护和分析问题：不做错误及多余调用。
谨慎继承
开发过程中要了解系统架构，特别是一些基类，公共组件，实现合理利用，减少大对象产生的可能。
程序算法优化
试着用算法来提高程序效率，例如，我们可以用二分法来做物料计划（不用扫描整个库存数据与物料需求的对比，我们只需要找到满足需要的库存数据即可停止遍历，这样做的效率至少可以提高一个数量级，当然也取决于库存数量与需求的物料种类及数量）。
批处理
对于大批量的数据处理，最好能够做成批处理，这样就不会因为单次操作而影响系统的正常使用。
延迟加载
对于大对象的展示，可以采用延迟加载的方式，层层递进地显示明细。例如，我们分页显示列表内容，往往只显示主表内容，附表内容在查看明细时才去请求。
防止内存泄漏
内存泄漏是由于对象无法回收造成的，特别是一些长生命周期的对象风险较大。例如，用户登录成功后，系统往往会把用户的状态保存在Session中，同一用户再次登录时（前一次并没有退出），我们会在Session中检查一下此用户是否已经在线，如果是就更新Session状态，不是就记录Session信息。另外，我们还会做一个过滤器，对于长时间不活动的用户进行Session过期处理。笔者以前碰到过系统不做这样的处理，最后导致内存溢出。
减少大对象引用
防止在程序中声明及实例化大对象，不能为了方便而设计出大对象。例如，有些工程师为了图方便，会把用户的功能权限，数据权限，用户信息都放在一个对象中，其占用的堆空间就比较大。而实际上系统中多数用户并不一定都要用到这些信息，所以这个对象中存放这么多信息就是浪费。因此，我们可以将其拆分成多个更小的类，或者使用如Redis这样的缓存区存储而不是放在堆内存中。
防止争用死锁
如果出现线程同步的场景，不同的线程对同一个资源，通常会导致等待，处理不当会导致死锁。可以适当的采用监听器，观察者模式来处理这类场景，核心思想就是同步向异步转化，如果是OLTP系统，在程序优化的背后还有数据库的优化，涉及表结构、索引、存储过程及内存分配等优化。
索引：编写合理的SQL，尽量利用索引。
存储过程
为了减少数据传输到应用程序层面，一般会在数据库层面利用存储过来完成数据的逻辑运算，只需要回传少量结果给应用层。当然，现在的分布式数据库并不主张用存储过程，数据库仅仅用来做存储，并从物理设计、并发处理方面来提升性能。
内存分配
合理地分配数据库内存，以Oracle为例，我们合理设置PGA与SG的大小；当然我们在操作数据库的同时也要避免冲击内存的上限，例如，对于大数据，不提供Order by的操作，避免PGA 区域被占满，即使允许排序，也要限定查询条件来减小数据集的范围。
并行
使用多个进程或者线程来处理任务，例如，Oracle中的并行查询，Tomcat的线程池。当然也要避免并行时的数据争用而导致的死锁，OLTP类型系统并行及数据争用的概率比较大，尤其要注意提高程序效率，减少争用对象的等待。程序要防止互锁(甲需要资源A、B，乙需要B、A；此时甲占有A等待B，正好乙占有B等待A，此时就容易互锁)。
异步
例如，用MQ(消息中间件)来解耦系统之间的依赖关系，减少阻塞。
使用好的设计模式来优化程序，例如，用回调来减少阻塞，使用监听器来阻塞依赖。
选择合适的IO模式，如 NIO、AIO 等。
缓存
把经常引用的数据缓存到内存中，提高读取的响应速度。这就是常说的空间换时间的概念。
分散压力 在性能优化中也可以分散数据来缓解压力。
例如我们每秒要处理200万条日志数据，分析这200万条数据中藏着的业务机会。我们首先想到的是把数据分而治之，例如，分成20个处理队列，这样每队处理10万条数据，分别进行分析。这样似乎没有问题，但仔细想想；这样性能够好吗？10万条数据按规则处理通常也得10秒左右(这已经是很快了)，能够更快吗？当然可以。可以预见不是每一条数据都有意义或者说能够产生商机，我们可以先排除无效数据，然后再进行分析，自然效率会更高。就如上面说的，把压力分散在各个环节，验证数据时去除掉一部分无效数据，要分析的样本流变少了，性能自然就上去了。
阅读后若有收获，不吝关注，分享，在看等操作！！！
