代码：
public interface BusinessProcess{
          void processBusiness();
}

public class BusinessProcessImpl implements BusinessProcess{
          public void processBusiness(){
                System.out.println("in businessProcessImpl");
           }
}

如果要对BusinessProcessImpl增加权限验证功能，那么静态代理代码：
public class BusinessProcessProxy implements BusinessProcess{
          private BusinessProcess target;
          public BusinessProcessProxy(BusinessProcess target){
                   this.target = target;
          }
          
          public void processBusiness(){
                 checkPermission();
                 this.target.processBusiness();
          }
}

对于动态代理:
public class PermissionHandler implements InvocationHandler {
     private Object target;
     public LoggerHandler(Object target){
        this.target = target;
    }

     public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        checkPermission();
        Object result = method.invoke(this.target,args);
         return result;
    }
}

测试代码：
        BusinessProcessImpl impl = new BusinessProcessImpl();
        PermissionHandler handler = new PermissionHandler (impl);
        BusinessProcess proxy = (BusinessProcess)Proxy.newProxyInstance(impl.getClass().getClassLoader(),impl.getClass().getInterfaces(), handler);
        proxy.processBusiness();

       注意：
      proxy对象是BusinessProcess接口的一个实现类，但是不是BusinessProcessImpl的子类

看起来好像静态代理和动态代理没什么区别，但是仔细一看，静态代理代理的target只能是BusinessProcess对象，而动态代理却能够代理任何一个Object对象，这就是关键区别。所以程序中不需要为每个核心类写一个Proxy，而公用一个就可以。

动态代理的实现原理：
byte[] proxyClassFile = ProxyGenerator.generateProxyClass(proxyName, interfaces);
proxyClass = defineClass0(loader, proxyName,proxyClassFile, 0,proxyClassFile.length);
这是java.lang.reflect.Proxy的两行关键代码，第一行代码生成名为proxyName, 实现的接口为interfaces的一个类的字节码。
第二行代码，将生成的字节码注入到classloader中去。

第一次为某个object生成proxyClass可能比较耗费性能，但是Proxy方法作了缓存，可以弥补这一点。此外，动态代理只能够对interfaces进行动态的代理, 也就是说它先找出需要代理的对象实现的所有的interface, 然后只对所有的这些interface的所有的方法代理，对象除了interfaces以外的方法不予处理。

一个朋友发了封mail问了几个问题，其中的一个是关于IoC和DI的：
Inversion of Control和Dependency Injection 是什么关系，我认为两个词代表的是同一个意思，只是两种不同的表示，对吗？

下面是我对这个问题的一些理解。
准确的说，IoC和DI并不相同，这一点从字面上就可以看出，否则，它们可以叫一个名字。^_^

理解IoC，我们需要知道Control是什么，它又是怎样被Inversion的。其实，IoC是用来说明“程序库”和“框架”区别的最好证据。在使用程序库的时候，控制权是掌握在我们手中的，我们编写的代码调用程序库的实现，完成相应的功能，想想我们使用JDK的情况。使用框架的时候，控制权则掌握在框架手中，我们的代码最终是由框架调用，一个常见的例子是Servlet，我们编写的Servlet代码是放在整个Servlet的框架中，由Web容器进行调用。这就是差异所在。我们更习惯于自己掌控一切，因此，对框架掌握控制权的这种情况，我们用“Inversion”来形容，这也是Martin Fowler在那篇给DI正名的文章中提到，所有框架都是IoC的原因。

Spring的核心容器是一个框架，所以，我们可以说它是IoC，但是就如前面所说，每个框架都有IoC，所以，仅仅用IoC是不足以说明一切的。Spring核心容器完成的是组件组装的过程，这是它和其它普通框架区别最为显著的地方。如果说用IoC描述这个框架，那么，这里所指的Control实际上是组件的组装过程。

站在Spring核心容器的层面上看，它完成组装过程是把组件所依赖的零部件给组件安装上去。站在单个组件层面上看，它所需要的零部件是由外部给它安装的，这个过程就像是把“Dependency”这管药水用注射器“Injection”到组件的身体中去，所以，我们称之为“Dependency Injection”。

完成组件组装的容器也不只是注入一种形式，还有一种常见的方式是“Dependency Lookup”，即每个组件自己去查找自己所需要的内容。至于到哪去找，也有不同的实现方式，有固定到某个地方（比如使用静态方法），有把查找点通过DI的方式注入进来等等。

Martin Fowler的文章已经很清楚的解释了IoC和DI这两个概念，我们只需要去细细品味。