前言：
今天自测时，发现自己写的一个批量设置页面有性能问题。目前的解决方法有三种：
1）利用多线程
2）要求接口提供方，提供批量接口
3）页面提示用户，批量设置已提交，在后台异步处理
这边博文记录解决该性能问题的全过程。
性能问题的细节描述：
页面系统A循环调用了功能系统B的单一设置接口Object.setup()方法，功能系统B的Object.setup()方法又调用底层系统C的两个接口，进行真正的setup操作，修改数据库bla..bla...
解决该问题的一个步骤：打日志。
首先确认是B和C哪个系统调用的时间最久，定位性能瓶颈点。编写代码：
第一次日志打印结果
说明调用应用B的接口有性能问题，排除应用C。
接下来针对应用B的接口实现，打印可能的性能瓶颈，首先定位的是一系列DAO操作。
第二次打印日志结果：
很明显，应用B-DAO数据库写入操作占用了很多时间。
小插曲one：
两个类同时实现同一个接口，怎么指定其中一个调用；可以在xml文件中指定，也可以根据加了标签
@Component("xxxDAO")，指定
@Resource(name="xxxDAO")
private AaaDAO AaaDAO;
小插曲two：
在log4j中配置，可以打印sql调用的日志：
实际情况确实比想象的还要复杂，因为定位到性能瓶颈点B-DAO并没有直接操作数据库，而是调用了应用D的接口，其中真正的性能瓶颈在应用D中。可以确定的是是更新操作确实有性能问题，update一次最好的情况需要100ms。然而调用一下D的DAO接口需要更新不止一次，所以会耗费500ms左右。
优化D的DAO数据库操作，仅仅抽取需要更新的属性“key”进行更新，之前是把所有属性进行更新。
优化后，发现性能仍然不满足需求，究其原因，最耗费时间的关键点在update数据库之前，需要check非常多的限制条件，这些校验正是瓶颈之处。
首先，check的过程是必要的，如果把必要的属性记录更新错或者删除，那么属性对应的对象就不可用，这样是非常危险的。但是内部系统调用应用D的更新接口，是否可以将check过程缩水甚至去掉，其中的风险和标准也是待评估的。
最终，暂时的解决方案是页面应用A中，新增进度条，标识批量设置的进度，当然页面等待时间就要调到很高，否则hsf接口调用会超时。
然而，应用D性能优化的具体方案仍然在评估中，对于check过程应该怎样优化……
此篇博文在实际编程中解决性能问题貌似已经结束。
但是，真正的性能调优仍然是——未完待续……