引言

首先说说在单核时代,异步回调应该也没有人会去使用,因为从CPU执行上来说异步回调除了不像同步回调那样执行时阻塞(阻止后面代码执行,即仍处于调用callback的线程的上下文中)外,可能与同步回调也差不多,最多可能做到一个关注点的分离,这意味着在单核时代我们几乎总是使用同步回调.但随着多核时代的到来,异步的优势慢慢体现,接下来就简单谈谈这两者之间的区别.

孰优孰劣

首先对于这两种方式本身来说没有一种是"更优"于另一种的,它们都有更适合于自己的场景,并不能一概而论,

同步回调

可以无竞争的访问线程本身的元素,比如thread_local,或者线程栈上元素.
触发回调和回调执行是同一个线程,不需要关系线程安全,直接执行函数即可.
代码编写简单

异步回调

触发回调和回调执行并不是一个线程,需要注意DataRace,需要我们进行指定执行顺序(互斥锁或指定内存序以到达同步).
不能访问thread_loacl和栈上元素
对于执行callback的线程来说的性能提升,异步回调意味着我们可以把耗时的IO操作全部放到其他线程执行,而我们本身的时间循环可以继续执行正常的逻辑,以此提升并发量.

有一句话很有意思,即同步回调 (sync callback) 在构造闭包的调用栈 (call stack) 里局部执行,这意味着同步回调中上下文的寿命一般长于用lambda表达式捕获后构造的回调,这使得我们不必担心捕获对象的生命周期问题,而异步回调往往闭包的寿命长过调用栈的长度,这使得其中捕获的对象可能在函数执行时已经死亡,同时对象也可能泄露,这类问题是有一个通解的,即shared_ptr/weak_ptr.关于回调中对象的所有权问题有一点值得讨论,即强引用(strong reference),这时闭包是拥有对象的所有权的,闭包何时被销毁,对象也何时被销毁,这用在我们希望回调执行时捕获对象总是有效.例子是用bind捕获shared_ptr,此时shared_ptr的生命周期等同于bind产生的对象(外界不存在引用计数的话).

所以我们不能一概的指出到底哪一个更好,举个简单的例子

std::foreach(callback);

此时这就是一个同步回调,在这种场景下我们也兵不需要异步回调.

while(Event_Driven_loop){
	if(connectionEvent){
		//dosomething
	}else if(IOEvent Event){
		blockingqueue.push(Event);
	}else if(CalculateEvent Event){
		blockingqueue.push(Event);
	}
	...
}

以上是一个事件驱动的循环,根据事件类型来执行不同的代码,当遇到计算任务和IO任务的时候,费时的操作我们可以扔到一个阻塞队列或者类似的工具中,这就是一个典型的异步回调,这样的好处时费时的操作可以不在宝贵的时间循环中进行,而开辟出专门的线程去做这件事,以此提升并发潜力.想象以下如果这个我们改成一个同步回调,那么如果在Event中有一个费时的操作,文件IO也好,DNS解析也好,又或是一个花费半秒的计算任务,这对于一个高性能的服务器来说是不可忍受的.

总结

其实大可不必纠结名词的含义,根据上面两个例子我们可以看出这其实就是问题的两种解决方案,各有优劣而已,无非是时机不同我们所的需求不同罢了.

参考:
https://blog.csdn.net/yunnysunny/article/details/44726963
再谈回调一篇好文