java直接调用与反射

代码参考：

package com.wj.test;

import java.lang.reflect.Method;

public class PerformanceTest {

 public static void main(String[] args) throws Exception {
  int testTime = 10;
  PerformanceTest test = new PerformanceTest();
  String msg = "this is test message";
  long bTime = System.nanoTime();
  for (int i = 0; i < testTime; i++) {
   test.takeAction(msg);
  }
  long eTime = System.nanoTime();
  System.out.println(eTime - bTime);

  Method method = test.getClass().getMethod("takeAction", String.class);

  bTime = System.nanoTime();
  for (int i = 0; i < testTime; i++) {
   method.invoke(test, msg);
  }
  eTime = System.nanoTime();
  System.out.println(eTime - bTime);

 }

 public int takeAction(String msg) {
  return (msg.length() * (int) (System.currentTimeMillis() % 100000));
 }

}

==========

打印：

5132 ns
166129 ns

 

总结：

在真实的开发场景，在系统发生一次调用过程中，发射的使用次数一般发生在个位数，发射影响的性能可以忽略不计。（利大于弊，反射创建的对象一般都缓存）

优化：要找准系统性能的瓶颈点。

考虑目前的计算机系统的速度，应用开发已经不在那么介意性能，而更为注重系统的可维护性和扩展性以及快速开发效率上。上述的测试结果是在一千万次的测试基础上产生的。而在通常的一次业务请求中，反射使用的次数应该是非常少的，只在框架级基础上被使用，在一个高负载的系统中，业务处理的性能将是关键点，而不在于使用的这些反射所带来的性能影响上。而使用反射所带来的开发便利与可维护性可扩展性的提升所带来的价值，是远远高于其所损耗的性能的。 

又回想起原来在某个所谓高性能项目中通过减少反射来提高性能的做法，现在想来，比较愚蠢。这说明前期的测试工作没到位，而带来这样的结论偏差，从而导致了开发与维护的不便，而且极大地影响了开发速度。 
其实那个系统的大部分性能瓶颈都是在数据库上，大部分的业务处理都是在数据库中进行的，在项目后面的性能测试中发现，WEB服务器的负载非常低，远远低于数据库，大部分的操作都是在等待数据库的返回。 
前期某些推论既没经过验证，也没相关的使用经验来支持此推论，是导致这种错误的根源。在将来的架构设计工作与框架型要加强这方面的评估工作，来达到性能与开发效率间的最佳平衡。