回调函数（callback）是什么？ 第1页

准备好一杯水，因为接下来的内容会很干。

读完后你将彻底告别回调函数的疑惑，并且你的武器库将新增一件功能强大的利器。

不知你是不是也有这样的疑惑，我们为什么需要回调函数这个概念呢？直接调用函数不就可以了？回调函数到底有什么作用？程序员到底该如何理解回调函数？

一切要从这样的需求说起

假设你们公司要开发下一代国民App“明日油条”，一款主打解决国民早餐问题的App，为了加快开发进度，这款应用由A小组和B小组协同开发。

其中有一个核心模块由A小组开发然后供B小组调用，这个核心模块被封装成了一个函数，这个函数就叫make_youtiao()。

如果make_youtiao()这个函数执行的很快并可以立即返回，那么B小组的同学只需要：

1. 调用make_youtiao()
2. 等待该函数执行完成
3. 该函数执行完后继续后续流程

从程序执行的角度看这个过程是这样的：

1. 保存当前被执行函数的上下文
2. 开始执行make_youtiao()这个函数
3. make_youtiao()执行完后，控制转回到调用函数中

如果世界上所有的函数都像make_youtiao()这么简单，那么程序员大概率就要失业了，还好程序的世界是复杂的，这样程序员才有了存在的价值。

现实情况并不容易

现实中make_youtiao()这个函数需要处理的数据非常庞大，假设有10000个，那么make_youtiao(10000)不会立刻返回，而是可能需要10分钟才执行完成并返回。

这时你该怎么办呢？想一想这个问题。

可能有的同学就像把头埋在沙子里的鸵鸟一样：和刚才一样直接调用不可以吗，这样多简单。

是的，这样做没有问题，但就像爱因斯坦说的那样“一切都应该尽可能简单，但是不能过于简单”。

想一想直接调用会有什么问题？

显然直接调用的话，那么调用线程会被阻塞暂停，在等待10分钟后才能继续运行。在这10分钟内该线程不会被操作系统分配CPU，也就是说该线程得不到任何推进。

这并不是一种高效的做法。

没有一个程序员想死盯着屏幕10分钟后才能得到结果。

那么有没有一种更加高效的做法呢？

想一想我们上一篇中那个一直盯着你写代码的老板(见

)，我们已经知道了这种一直等待直到另一个任务完成的模式叫做同步。

如果你是老板的话你会什么都不干一直盯着员工写代码吗？因此一种更好的做法是程序员在代码的时候老板该干啥干啥，程序员写完后自然会通知老板，这样老板和程序员都不需要相互等待，这种模式被称为异步。

回到我们的主题，这里一种更好的方式是调用make_youtiao()这个函数后不再等待这个函数执行完成，而是直接返回继续后续流程，这样A小组的程序就可以和make_youtiao()这个函数同时进行了，就像这样：

在这种情况下，回调(callback)就必须出场了。

在正式讲解回调函数之前，除了本文提到的回调编程技巧之外算法能力也比不可少，在这里我也送一本帮我拿到BAT等一线大厂offer的算法笔记，是一位阿里大神写的，对于算法薄弱或者需要提高的同学是否有用，分享给大家，希望这份笔也能帮到你

为什么我们需要回调callback

有的同学可能还没有明白为什么在这种情况下需要回调，别着急，我们慢慢讲。

假设我们“明日油条”App代码第一版是这样写的：

       make_youtiao(10000); sell();     

可以看到这是最简单的写法，意思很简单，制作好油条后卖出去。

我们已经知道了由于make_youtiao(10000)这个函数10分钟才能返回，你不想一直死盯着屏幕10分钟等待结果，那么一种更好的方法是让make_youtiao()这个函数知道制作完油条后该干什么，即，更好的调用make_youtiao的方式是这样的：“制作10000个油条，炸好后卖出去”，因此调用make_youtiao就变出这样了：

       make_youtiao(10000, sell);     

看到了吧，现在make_youtiao这个函数多了一个参数，除了指定制作油条的数量外还可以指定制作好后该干什么，第二个被make_youtiao这个函数调用的函数就叫回调，callback。

现在你应该看出来了吧，虽然sell函数是你定义的，但是这个函数却是被其它模块调用执行的，就像这样：

make_youtiao这个函数是怎么实现的呢，很简单：

       void make_youtiao(int num, func call_back) {     // 制作油条     call_back(); //执行回调  }     

这样你就不用死盯着屏幕了，因为你把make_youtiao这个函数执行完后该做的任务交代给make_youtiao这个函数了，该函数制作完油条后知道该干些什么，这样就解放了你的程序。

有的同学可能还是有疑问，为什么编写make_youtiao这个小组不直接定义sell函数然后调用呢？

不要忘了明日油条这个App是由A小组和B小组同时开发的，A小组在编写make_youtiao时怎么知道B小组要怎么用这个模块，假设A小组真的自己定义sell函数就会这样写：

       void make_youtiao(int num) {     real_make_youtiao(num);     sell(); //执行回调  }     

同时A小组设计的模块非常好用，这时C小组也想用这个模块，然而C小组的需求是制作完油条后放到仓库而不是不是直接卖掉，要满足这一需求那么A小组该怎么写呢？

       void make_youtiao(int num) {     real_make_youtiao(num);      if (Team_B) {        sell(); // 执行回调     } else if (Team_D) {        store(); // 放到仓库     } }     

故事还没完，假设这时D小组又想使用呢，难道还要接着添加if else吗？这个问题该怎么解决呢？关于这个问题的答案，你懂的。

新的编程思维模式

让我们再来仔细的看一下这个过程。

程序员最熟悉的思维模式是这样的：

1. 调用某个函数，获取结果
2. 处理获取到的结果

       res = request(); handle(res);     

这就是函数的同步调用，只有request()函数返回拿到结果后，才能调用handle函数进行处理，request函数返回前我们必须等待，这就是同步调用，其控制流是这样的：

但是如果我们想更加高效的话，那么就需要异步调用了，我们不去直接调用handle函数，而是作为参数传递给request：

       request(handle);     

我们根本就不关心request什么时候真正的获取的结果，这是request该关心的事情，我们只需要把获取到结果后该怎么处理告诉request就可以了，因此request函数可以立刻返回，真的获取结果的处理可能是在另一个线程、进程、甚至另一台机器上完成。

这就是异步调用，其控制流是这样的：

从编程思维上看，异步调用和同步有很大的差别，如果我们把处理流程当做一个任务来的话，那么同步下整个任务都是我们来实现的，但是异步情况下任务的处理流程被分为了两部分：

1. 第一部分是我们来处理的，也就是调用request之前的部分
2. 第二部分不是我们处理的，而是在其它线程、进程、甚至另一个机器上处理的。

我们可以看到由于任务被分成了两部分，第二部分的调用不在我们的掌控范围内，同时只有调用方才知道该做什么，因此在这种情况下回调函数就是一种必要的机制了。

也就是说回调函数的本质就是“只有我们才知道做些什么，但是我们并不清楚什么时候去做这些，只有其它模块才知道，因此我们必须把我们知道的封装成回调函数告诉其它模块”。

现在你应该能看出异步回调这种编程思维模式和同步的差异了吧。

接下来我们给回调一个较为学术的定义

正式定义

在计算机科学中，回调函数是指一段以参数的形式传递给其它代码的可执行代码。

这就是回调函数的定义了。

回调函数就是一个函数，和其它函数没有任何区别。

注意，回调函数是一种软件设计上的概念，和某个编程语言没有关系，几乎所有的编程语言都能实现回调函数。

对于一般的函数来说，我们自己编写的函数会在自己的程序内部调用，也就是说函数的编写方是我们自己，调用方也是我们自己。

但回调函数不是这样的，虽然函数编写方是我们自己，但是函数调用方不是我们，而是我们引用的其它模块，也就是第三方库，我们调用第三方库中的函数，并把回调函数传递给第三方库，第三方库中的函数调用我们编写的回调函数，如图所示：

而之所以需要给第三方库指定回调函数，是因为第三方库的编写者并不清楚在某些特定节点，比如我们举的例子油条制作完成、接收到网络数据、文件读取完成等之后该做什么，这些只有库的使用方才知道，因此第三方库的编写者无法针对具体的实现来写代码，而只能对外提供一个回调函数，库的使用方来实现该函数，第三方库在特定的节点调用该回调函数就可以了。

另一点值得注意的是，从图中我们可以看出回调函数和我们的主程序位于同一层中，我们只负责编写该回调函数，但并不是我们来调用的。

最后值得注意的一点就是回调函数被调用的时间节点，回调函数只在某些特定的节点被调用，就像上面说的油条制作完成、接收到网络数据、文件读取完成等，这些都是事件，也就是event，本质上我们编写的回调函数就是用来处理event的，因此从这个角度看回调函数不过就是event handler，因此回调函数天然适用于事件驱动编程event-driven，我们将会在后续文章中再次回到这一主题。

回调的类型

我们已经知道有两种类型的回调，这两种类型的回调区别在于回调函数被调用的时机。

注意，接下来会用到同步和异步的概念，对这两个概念不熟悉的同学可以参考上一篇文章

同步回调

这种回调就是通常所说的同步回调synchronous callbacks、也有的将其称为阻塞式回调blocking callbacks，或者什么修饰都没有，就是回调，callback，这是我们最为熟悉的回调方式。

当我们调用某个函数A并以参数的形式传入回调函数后，在A返回之前回调函数会被执行，也就是说我们的主程序会等待回调函数执行完成，这就是所谓的同步回调。

有同步回调就有异步回调。

回调对应的编程思维模式

让我们用简单的几句话来总结一下回调下与常规编程思维模式的不同。

假设我们想处理某项任务，这项任务需要依赖某项服务S，我们可以将任务的处理分为两部分，调用服务S前的部分PA，和调用服务S后的部分PB。

在常规模式下，PA和PB都是服务调用方来执行的，也就是我们自己来执行PA部分，等待服务S返回后再执行PB部分。

但在回调这种方式下就不一样了。

在这种情况下，我们自己来执行PA部分，然后告诉服务S：“等你完成服务后执行PB部分”。

因此我们可以看到，现在一项任务是由不同的模块来协作完成的。

即：

• 常规模式：调用完S服务后后我去执行X任务，
  
• 回调模式：调用完S服务后你接着再去执行X任务，
  

其中X是服务调用方制定的，区别在于谁来执行。

为什么异步回调这种思维模式正变得的越来越重要

在同步模式下，服务调用方会因服务执行而被阻塞暂停执行，这会导致整个线程被阻塞，因此这种编程方式天然不适用于高并发动辄几万几十万的并发连接场景，

针对高并发这一场景，异步其实是更加高效的，原因很简单，你不需要在原地等待，因此从而更好的利用机器资源，而回调函数又是异步下不可或缺的一种机制。

回调地狱，callback hell

有的同学可能认为有了异步回调这种机制应付起一切高并发场景就可以高枕无忧了。

实际上在计算机科学中还没有任何一种可以横扫一切包治百病的技术，现在没有，在可预见的将来也不会有，一切都是妥协的结果。

那么异步回调这种机制有什么问题呢？

实际上我们已经看到了，异步回调这种机制和程序员最熟悉的同步模式不一样，在可理解性上比不过同步，而如果业务逻辑相对复杂，比如我们处理某项任务时不止需要调用一项服务，而是几项甚至十几项，如果这些服务调用都采用异步回调的方式来处理的话，那么很有可能我们就陷入回调地狱中。

举个例子，假设处理某项任务我们需要调用四个服务，每一个服务都需要依赖上一个服务的结果，如果用同步方式来实现的话可能是这样的：

       a = GetServiceA(); b = GetServiceB(a); c = GetServiceC(b); d = GetServiceD(c);     

代码很清晰，很容易理解有没有。

我们知道异步回调的方式会更加高效，那么使用异步回调的方式来写将会是什么样的呢？

       GetServiceA(function(a){     GetServiceB(a, function(b){         GetServiceC(b, function(c){             GetServiceD(c, function(d) {                 ....             });         });     }); });     

我想不需要再强调什么了吧，你觉得这两种写法哪个更容易理解，代码更容易维护呢？

博主有幸曾经维护过这种类型的代码，不得不说每次增加新功能的时候恨不得自己化为两个分身，一个不得不去重读一边代码；另一个在一旁骂自己为什么当初选择维护这个项目。

异步回调代码稍不留意就会跌到回调陷阱中，那么有没有一种更好的办法既能结合异步回调的高效又能结合同步编码的简单易读呢？

幸运的是，答案是肯定的。

总结

在这里，我们从一个实际的例子出发详细讲解了回调函数这种机制的来龙去脉，这是应对高并发、高性能场景的一种极其重要的编码机制，异步加回调可以充分利用机器资源，实际上异步回调最本质上就是事件驱动编程。

最后，经常有同学问有没有推荐的计算机书籍，在这统一说下，书单这东西贵精不贵多，我在这里精心挑选了10本 ，不要贪心，如果你真能把这里推荐的 10 本书读通，可以说你已经能超越 90% 的程序员了

最后的最后，博主在知乎上分享过很多文章，有很多知乎朋友问有没有完整的pdf版本，这个我也整理出来了，绘图非常精美，14万字，这里还汇总了部分知乎问题，我为其专门设计了封面，并将其命名为《计算机底层的秘密》，现在免费分享给大家。

希望该回答能解答你的疑问。

Github: GitHub - xfenglu/everycodershouldknow: 码农的荒岛求生

回调函数的意思是“把函数A作为参数传递给另一个函数B”。

维基百科的解释：

a callback is a piece of executable code that is passed as an argument to other code, which is expected to call back (execute) the argument at some convenient time.

为什么要这样做呢？为什么不把定义好的函数放在头文件中呢？

因为可以作为参数的函数A的名称和实现可以被抽象出来，也就是在写函数B的时候，不需要管函数A叫什么名字，怎么实现，只要函数A的返回类型是一定的就可以了（泛型的话连这个也不需要）。

比如某人写了一个画图的库，把具体怎么画留给使用库的人定义。使用库的人就可以自定义画图函数的名称和实现方式。

例子(C++)：

非泛型

定义库(library.h)

       #include <cstdio> void fill_screen(int (*some_func)(void)) {printf("%d
",some_func());}      

使用库的时候：

       #include "library.h"  int draw_this_way() {return 0;} int draw_that_way() {return 1;} int draw_yet_another_way() {return 2;}  int main() {    fill_screen(&draw_this_way);    fill_screen(&draw_that_way);    fill_screen(&draw_yet_another_way);       return 0; }      

编译:

       g++ callback.cpp -o callback      

结果：

       $./callback 0 1 2     

泛型

定义库(library.h)：

       # include <iostream> template<typename ANY_TYPE> void fill_screen(ANY_TYPE (*some_func)(void)) { std::cout << some_func() << std::endl;}      

使用库的时候：

       #include "library.h"  int draw_this_way() {return 0;} char draw_that_way() {return 'a';} bool draw_yet_another_way() {return true;}   int main() {     fill_screen(&draw_this_way);     fill_screen(&draw_that_way);     fill_screen(&draw_yet_another_way);     return 0; }      

编译:

       g++ callback.cpp -o callback      

结果：

       $./callback 0 a 1     

补充：

委托和回调

委托是一种设计模式。意思是A类把自己的工作交给B类完成。简单的委托相当与在A的方法中调用了B的方法。

使用委托可以把库的定义和具体使用分开。比如数据库的基本操作是CRUD，但是每个不同数据库具体api不同，对于使用者而言不可能逐个掌握所有数据库的api，所以出现了api的wrapper，用户只用掌握一套CRUD的api就可以使用所有数据库了。

在某些不能直接将函数作为参数传递的语言（比如java）中，委托是实现回调功能的一种方式。

具体而言，库的作者定义一个接口，在他的方法中调用这个接口，但是把接口的实现留给具体使用的人。在使用的时候，使用者新建一个匿名接口，并且重载要调用的接口方法。 这个过程相当与库的作者将工作通过接口“委托”给了使用者。

这个委托的过程相对比较复杂，打个生活中的比方：“领导不但把工作推脱给下属，还要对他们具体怎么干指手画脚。”

这里的领导是库的使用者，下属是库的定义，推脱是指调用下属的工作函数，指手画脚是指对工作函数调用的接口给予具体定义。

以下是java的例子。

定义库 (DrawLibrary.java)

       public class DrawLibrary {     public interface DrawInterface  {         int draw();     }      public static void fillScreen(DrawInterface someObj) {         System.out.println(someObj.draw());     } }     

使用库(Graphics.java)

       public class Graphics {     public static void drawThisWay() {         DrawLibrary.fillScreen( new DrawLibrary.DrawInterface() {             @Override             public int draw() {                 return 0;             }         });     }     public static void drawThatWay() {         DrawLibrary.fillScreen( new DrawLibrary.DrawInterface() {             @Override             public int draw() {                 return 1;             }         });     }     public static void drawYetAnotherWay() {         DrawLibrary.fillScreen( new DrawLibrary.DrawInterface() {             @Override             public int draw() {                 return 2;             }         });     }      public static void main(String[] args) {         drawThisWay();         drawThatWay();         drawYetAnotherWay();     } }     

编译：

       $javac Graphics.java $java Graphics      

结果：

       0 1 2     

这种设计模式经常在事件驱动的设计中看到，比如监听按钮是否被按下等等。

一帮装 x人士,把回调函数写得那么高大上干嘛?

首先回调函数就是一个函数,形式上和其他函数没有半点区别.

只不过这个所谓的回调函数是将要被当做参数传递给另一个函数,并被其调用(区别就在这,一般函数的形参,接收的是一个基本类型的变量,而这个函数,接受的参数居然是一个"函数",这个作为参数的函数,就叫回调函数)

举个例子:

一般函数:function a(int a, String b):接收的参数是一般类型.

特殊函数:function b(function c):接收的参数是一个函数,c这个函数就叫回调函数.

你也可以这么理解:本质区别是,一般一个函数调用另一个函数,被调用的函数是出现在方法体当中,而回调函数比较特殊,它是出现在参数列表当中.也就是说,当调用的时候,需要从其他地方拿到这个(回调)函数,以参数的形式传入.

一般的函数调用,可以称作是调用.然而另一种,执行时才将某个函数传入再调用的调用方式,就叫"回调",当然,不要纠结于翻译的准不准,主要需要理解本质是什么.

完全面向对象的语言(例如Java)中没有回调函数的概念,因为"接口"(中的方法)充当了回调函数的作用,也就是说上面的函数b接收的对象是一个接口的实现类对象

回调函数的概念一般在面向过程或者函数式编程中才出现.

学过Java语言的童鞋很好理解回调函数,其实就是一个函数的参数是某个接口的实现类.

初学者对回调函数的理解,可以认为是有个功能我自己不写,交给别人来写,他写完之后,我运行我的程序时,把那个函数传给我就行,然后我来调用他写的函数,实现我的功能.程序灵活性就有了,因为这个功能就可以有多种实现方式而不需要我关心具体实现细节.(另外其他回答中强调"回调"的含义,我也来解释下,回调是针对于被调用的函数来说的,也就是相对于写回调函数的人来说的,我写好一个函数,等着被调用(等着被回调))

理解回调函数,重点就是:回调函数是作为另一个函数的形参出现的,这和传统思维有很大不同.