(转载)
回调你可以这样来理解：
A发送消息给B，B处理好A要求的事情后，将结果返回给A，A再对B返回的结果来做进一步的处理。
1、回调的实现
1. /**
2. * 回调接口
3. * @author KOOK
4. *
5. */
6. public interface
7. /**
8. * 执行回调方法
9. * @param objects 将处理后的结果作为参数返回给回调方法
10. */
11. public void
12. }
2、 消息的发送者
1. /**
2. * 简单本地发送异步消息的类
3. * @author KOOK
4. *
5. */
6. public class Local implements
7.
8. /**
9. * 远程接收消息的类，模拟point-to-point
10. */
11. private
12.
13. /**
14. * 发送出去的消息
15. */
16. private
17.
18. public
19. super();
20. this.remote = remote;
21. this.message = message;
22. }
23.
24. /**
25. * 发送消息
26. */
27. public void
28. {
29. /**当前线程的名称**/
30. System.out.println(Thread.currentThread().getName());
31. /**创建一个新的线程发送消息**/
32. new Thread(this);
33. thread.start();
34. /**当前线程继续执行**/
35. "Message has been sent by Local~!");
36. }
37.
38. /**
39. * 发送消息后的回调函数
40. */
41. public void
42. /**打印返回的消息**/
43. 0]);
44. /**打印发送消息的线程名称**/
45. System.out.println(Thread.currentThread().getName());
46. /**中断发送消息的线程**/
47. Thread.interrupted();
48. }
49.
50. public static void
51. {
52. new Local(new Remote(),"Hello");
53.
54. local.sendMessage();
55. }
56.
57. public void
58. this);
59.
60. }
61. }3、 远程消息的接收者
1. /**
2. * 处理消息的远程类
3. * @author KOOK
4. *
5. */
6. public class
7.
8. /**
9. * 处理消息
10. * @param msg 接收的消息
11. * @param callBack 回调函数处理类
12. */
13. public void
14. {
15. /**模拟远程类正在处理其他事情，可能需要花费许多时间**/
16. for(int i=0;i<1000000000;i++)
17. {
18.
19. }
20. /**处理完其他事情，现在来处理消息**/
21. System.out.println(msg);
22. "I hava executed the message by Local");
23. /**执行回调**/
24. new String[]{"Nice to meet you~!"});
25. }
26.
27. }
执行Local类的main方法。
注意Local类中红色背景的那行：
remote.executeMessage(message, this);
executeMessage方法需要接收一个message参数，表示发送出去的消息，而CallBack参数是他自己，也就是这里的this。表示发送消息后，由Local类自己来处理，调用自身的execute方法来处理消息结果。
如果这里不是用this，而是用其他的CallBack接口的实现类的话，那就不能称之为“回调”了，在OO的世界里，那就属于“委派”。也就是说，“回调”必须是消息的发送者来处理消息结果，否则不能称之为回调。这个概念必须明确。
——————————————————————————————————————————————————————————
Java回调机制解析
模块之间总是存在这一定的接口，从调用方式上看，可以分为三类：同步调用、回调和异步调用。同步调用是一种阻塞式调用，也是我们在写程序中经常使用的；回调是一种双向的调用模式，也就是说，被调用的接口被调用时也会调用对方的接口，这句话可能有点绕，等文章后面举例说明；异步调用是一种类似消息或事件的机制，解决了同步阻塞的问题，举例来讲：A通知B后，他们各走各的路，互不影响，不用像同步调用那样，A通知B后，非得等到B走完后，A才继续走。回调是异步的基本，因此下面着重说回调机制。
我们暂且不讨论回调的一些名词和运行机制，首先说为什么会存在回调这样一种调用？同步和异步机制的出现不必多说，大家心知肚明，那回调机制为什么会出现呢？在我们现实生活中，有如下这样场景：有一位老板很忙，他没有时间盯着员工干活，然后他告诉自己的雇员，干完当前这些事情后，告诉他干活的结果。这个例子其实是一个回调+异步的例子，再举一个例子，A程序员写了一段程序a，其中预留了回调函数接口，并封装好了该程序，程序员B让a调用自己的程序b中的一个方法，于是，他通过a中的接口回调自己b中的方法，到这里你可能似懂非懂了，后面会继续说明回调的出现原因。接下来我们把上面例子变成代码，看到网上很多人最后搞混了异步和回调，因此例子中不加入异步调用。（ 注意：回调可不是解决什么调用时间过长问题，那是异步！）
首先创建一个回调接口，让老板得告知干完活如何找到他的方式：留下老板办公室地址：
1. package
2.
3. /**
4. * 此接口为联系的方式，不论是电话号码还是联系地址，作为
5. * 老板都必须要实现此接口
6. * @author Administrator
7. *
8. */
9. publicinterface
10.
11. publicvoid
12. }
创建回调对象，就是老板本人，因为员工干完活后要给他打电话，因此老板必须实现回调接口，不然员工去哪里找老板？
1. package
2.
3. /**
4. * 老板是作为上层应用身份出现的，下层应用（员工）是不知道
5. * 有哪些方法，因此他想被下层应用（员工）调用必须实现此接口
6. * @author Administrator
7. *
8. */
9. publicclass Boss implements
10.
11. @Override
12. publicvoid
13. "收到了！！"
14.
15. }
16. }
创建控制类，也就是员工对象，他必须持有老板的地址（回调接口），即使老板换了一茬又一茬，办公室不变，总能找到对应的老板。
1. package
2.
3. /**
4. * 员工类，必须要记住，这是一个底层类，底层是不了解上层服务的
5. * @author Administrator
6. *
7. */
8. publicclass
9.
10. privatenull;
11.
12. //告诉老板的联系方式，也就是注册
13. publicvoid
14. this.callBack = callBack;
15. }
16.
17. //工人干活
18. publicvoid
19. //1.开始干活了
20. for(int i=0;i<10;i++){
21. "第【""】事情干完了！");
22. }
23.
24. //2.告诉老板干完了
25. callBack.execute();
26. }
27. }
测试类代码：
1. package
2.
3. publicclass
4.
5. publicstatic void
6.
7.
8. new
9.
10. //将回调对象（上层对象）传入，注册
11. new
12.
13. //开启控制器对象运行
14. emp.doSome();
15. }
16.
17. }
上面这个例子，大家可以和程序员A和程序员B的那个例子结合对照下。
看了上面的例子，有的人可能认为，这不是面向接口的编程吗？怎么会是回调，你再好好想想，咱们面向接口的编程的调用关系？在三层中，当业务层调用数据层时，是不需要把业务层自身传递到数据层的，并且这是一种上层调用下层的关系，比如我们在用框架的时候，一般直接调用框架提供的API就可以了，但回调不同，当框架不能满足需求，我们想让框架来调用自己的类方法，怎么做呢？总不至于去修改框架吧。许多优秀的框架提几乎都供了相关的接口，我们只需要实现相关接口，即可完成了注册，然后在合适的时候让框架来调用我们自己的类，还记不记得我们在使用Struts时，当我们编写Action时，就需要继承Action类，然后实现execute()方法，在execute()方法中写咱们自己的业务逻辑代码，完成对用户请求的处理。由此可以猜测，框架和容器中会提供大量的回调接口，以满足个性化的定制。
不知道上面这个例子懂了没有？我们现在可以想象Filter和Interceptor的区别了，这两者其中最大的一个区别是Filter是基于回调函数，需要容器的支持，没有容器是无法回调doFilter()方法，而Interceptor是基于Java的反射机制的，和容器无关。那到此是否又将反射和回调搞混了呢？请见我讲Java动态代理的博客《以此之长，补彼之短----AOP(代理模式)》。
总之，要明确的一点是，首先要搞清回调函数出现的原因，也就是适用场景，才能搞清楚回调机制，不然事倍功半。
最后，再举一例，为了使我们写的函数接近完美，就把一部分功能外包给别人，让别人个性化定制，至于别人怎么实现不管，我唯一要做的就是定义好相关接口，这一设计允许了底层代码调用高层定义的子程序，增强程序灵活性，和反射有着异曲同工之妙，我觉得这才是回调的真正原因，以上是我个人一些理解，望讨论！
模块之间总是存在这一定的接口，从调用方式上看，可以分为三类：同步调用、回调和异步调用。同步调用是一种阻塞式调用，也是我们在写程序中经常使用的；回调是一种双向的调用模式，也就是说，被调用的接口被调用时也会调用对方的接口，这句话可能有点绕，等文章后面举例说明；异步调用是一种类似消息或事件的机制，解决了同步阻塞的问题，举例来讲：A通知B后，他们各走各的路，互不影响，不用像同步调用那样，A通知B后，非得等到B走完后，A才继续走。回调是异步的基本，因此下面着重说回调机制。
我们暂且不讨论回调的一些名词和运行机制，首先说为什么会存在回调这样一种调用？同步和异步机制的出现不必多说，大家心知肚明，那回调机制为什么会出现呢？在我们现实生活中，有如下这样场景：有一位老板很忙，他没有时间盯着员工干活，然后他告诉自己的雇员，干完当前这些事情后，告诉他干活的结果。这个例子其实是一个回调+异步的例子，再举一个例子，A程序员写了一段程序a，其中预留了回调函数接口，并封装好了该程序，程序员B让a调用自己的程序b中的一个方法，于是，他通过a中的接口回调自己b中的方法，到这里你可能似懂非懂了，后面会继续说明回调的出现原因。接下来我们把上面例子变成代码，看到网上很多人最后搞混了异步和回调，因此例子中不加入异步调用。（
注意：回调可不是解决什么调用时间过长问题，那是异步！）
首先创建一个回调接口，让老板得告知干完活如何找到他的方式：留下老板办公室地址：
1. package
2.
3. /**
4. * 此接口为联系的方式，不论是电话号码还是联系地址，作为
5. * 老板都必须要实现此接口
6. * @author Administrator
7. *
8. */
9. publicinterface
10.
11. publicvoid
12. }
创建回调对象，就是老板本人，因为员工干完活后要给他打电话，因此老板必须实现回调接口，不然员工去哪里找老板？
1. package
2.
3. /**
4. * 老板是作为上层应用身份出现的，下层应用（员工）是不知道
5. * 有哪些方法，因此他想被下层应用（员工）调用必须实现此接口
6. * @author Administrator
7. *
8. */
9. publicclass Boss implements
10.
11. @Override
12. publicvoid
13. "收到了！！"
14.
15. }
16. }
创建控制类，也就是员工对象，他必须持有老板的地址（回调接口），即使老板换了一茬又一茬，办公室不变，总能找到对应的老板。
1. package
2.
3. /**
4. * 员工类，必须要记住，这是一个底层类，底层是不了解上层服务的
5. * @author Administrator
6. *
7. */
8. publicclass
9.
10. privatenull;
11.
12. //告诉老板的联系方式，也就是注册
13. publicvoid
14. this.callBack = callBack;
15. }
16.
17. //工人干活
18. publicvoid
19. //1.开始干活了
20. for(int i=0;i<10;i++){
21. "第【""】事情干完了！");
22. }
23.
24. //2.告诉老板干完了
25. callBack.execute();
26. }
27. }
测试类代码：
1. package
2.
3. publicclass
4.
5. publicstatic void
6.
7.
8. new
9.
10. //将回调对象（上层对象）传入，注册
11. new
12.
13. //开启控制器对象运行
14. emp.doSome();
15. }
16.
17. }
上面这个例子，大家可以和程序员A和程序员B的那个例子结合对照下。
看了上面的例子，有的人可能认为，这不是面向接口的编程吗？怎么会是回调，你再好好想想，咱们面向接口的编程的调用关系？在三层中，当业务层调用数据层时，是不需要把业务层自身传递到数据层的，并且这是一种上层调用下层的关系，比如我们在用框架的时候，一般直接调用框架提供的API就可以了，但回调不同，当框架不能满足需求，我们想让框架来调用自己的类方法，怎么做呢？总不至于去修改框架吧。许多优秀的框架提几乎都供了相关的接口，我们只需要实现相关接口，即可完成了注册，然后在合适的时候让框架来调用我们自己的类，还记不记得我们在使用Struts时，当我们编写Action时，就需要继承Action类，然后实现execute()方法，在execute()方法中写咱们自己的业务逻辑代码，完成对用户请求的处理。由此可以猜测，框架和容器中会提供大量的回调接口，以满足个性化的定制。
不知道上面这个例子懂了没有？我们现在可以想象Filter和Interceptor的区别了，这两者其中最大的一个区别是Filter是基于回调函数，需要容器的支持，没有容器是无法回调doFilter()方法，而Interceptor是基于Java的反射机制的，和容器无关。那到此是否又将反射和回调搞混了呢？请见我讲Java动态代理的博客《以此之长，补彼之短----AOP(代理模式)》。
总之，要明确的一点是，首先要搞清回调函数出现的原因，也就是适用场景，才能搞清楚回调机制，不然事倍功半。
最后，再举一例，为了使我们写的函数接近完美，就把一部分功能外包给别人，让别人个性化定制，至于别人怎么实现不管，我唯一要做的就是定义好相关接口，这一设计允许了底层代码调用高层定义的子程序，增强程序灵活性，和反射有着异曲同工之妙，我觉得这才是回调的真正原因，以上是我个人一些理解，望讨论！
