hello，大家好呀，我是小樓。

最近一個(gè)技術(shù)群有同學(xué)at我，問(wèn)我是否熟悉Dubbo，這我熟啊~

他說(shuō)遇到了一個(gè)Dubbo異步調(diào)用的問(wèn)題，懷疑是個(gè)BUG，提到BUG我可就不困了，說(shuō)不定可以水，哦不...寫一篇文章。

問(wèn)題復(fù)現(xiàn)

遇到問(wèn)題，尤其不是自己遇到的，必須要復(fù)現(xiàn)出來(lái)才好排查，截一個(gè)當(dāng)時(shí)的聊天記錄：

他的問(wèn)題原話是：

今天發(fā)現(xiàn)一個(gè)問(wèn)題 有一個(gè)dubbo接口返回類型是boolean， 把接口從同步改成異步 server 端返回true 消費(fèi)端卻返回false，把boolean改成Boolean就能正常返回結(jié)果 有碰到過(guò)這個(gè)問(wèn)題嗎

注意幾個(gè)重點(diǎn)：

• 接口返回類型是boolean
• 同步改為異步調(diào)用返回的boolean和預(yù)期不符合
• boolean基本類型改成包裝類型Boolean就能正常返回

聽到這個(gè)描述，我的第一反應(yīng)是這個(gè)返回結(jié)果定義為boolean肯定有問(wèn)題！

《Java開發(fā)手冊(cè)》中就強(qiáng)調(diào)了RPC接口返回最好不要使用基本類型，而要使用包裝類型：

但這個(gè)是業(yè)務(wù)編碼規(guī)范，如果RPC框架不能使用boolean作為返回值，豈不是個(gè)BUG？而且他強(qiáng)調(diào)了是同步改為異步調(diào)用才出現(xiàn)這種情況，說(shuō)明同步?jīng)]問(wèn)題，有可能是異步調(diào)用的鍋。

于是我順口問(wèn)了Dubbo的版本，說(shuō)不定是某個(gè)版本的BUG。得到回復(fù)，是2.7.4版本的Dubbo。

于是我拉了個(gè)工程準(zhǔn)備復(fù)現(xiàn)這個(gè)問(wèn)題。

哎，等等~

Dubbo異步調(diào)用的寫法可多了，于是我又問(wèn)了下他是怎么寫的。

知道怎么寫的就好辦了，寫個(gè)Demo先：

定義Dubbo接口，一個(gè)返回boolean，一個(gè)返回Boolean

public interface DemoService {
    boolean isUser();
    Boolean isFood();
}

實(shí)現(xiàn)Provider，為了簡(jiǎn)單，都返回true，并且打了日志

@Service
public class DemoServiceImpl implements DemoService {

    @Override
    public boolean isUser() {
        System.out.println("server is user : true");
        return true;
    }

    @Override
    public Boolean isFood() {
        System.out.println("server is food : true");
        return true;
    }
}

實(shí)現(xiàn)Consumer，為了方便調(diào)用，實(shí)現(xiàn)了一個(gè)Controller，為了防止本機(jī)調(diào)用，injvm設(shè)置為false，這里是經(jīng)驗(yàn)，injvm調(diào)用邏輯和遠(yuǎn)程調(diào)用區(qū)別挺大，為了防止干擾，統(tǒng)一遠(yuǎn)程調(diào)用。

@RestController
public class DemoCallerService {

    @Reference(injvm = false, check = false)
    private DemoService demoService;

    @GetMapping(path = "/isUser")
    public String isUser() throws Exception {
        BlockingQueue<Boolean> q = new ArrayBlockingQueue<>(1);
        RpcContext.getContext().asyncCall(
                () -> demoService.isUser()
        ).handle(
                (isUser, throwable) -> {
                    System.out.println("client is user = " + isUser);
                    q.add(isUser);
                    return isUser;
                });
        q.take();
        return "ok";
    }

    @GetMapping(path = "/isFood")
    public String isFood() throws Exception {
        BlockingQueue<Boolean> q = new ArrayBlockingQueue<>(1);
        RpcContext.getContext().asyncCall(
                () -> demoService.isFood()
        ).handle(
                (isFood, throwable) -> {
                    System.out.println("client is food = " + isFood);
                    q.add(isFood);
                    return isFood;
                });
        q.take();
        return "ok";
    }
}

啟動(dòng)一個(gè)Provider，再啟動(dòng)一個(gè)Consumer進(jìn)行測(cè)試，果然和提問(wèn)的同學(xué)表現(xiàn)一致：

• 先調(diào)用isUser（返回boolean），控制臺(tái)打?。?/li>

// client ...
client is user = false
// server ...
server is user : true

• 再調(diào)用isFood（返回Boolean），控制臺(tái)打印：

// client ...
client is food = true
// server ...
server is food : true

問(wèn)題排查

• Debug

先猜測(cè)一下是哪里的問(wèn)題，server端返回true，應(yīng)該問(wèn)題不大，可能是client端哪里轉(zhuǎn)換出錯(cuò)了。但這都是猜想，我們直接從client端接收到的數(shù)據(jù)開始，如果接收的數(shù)據(jù)沒(méi)問(wèn)題，肯定就是后續(xù)處理出了點(diǎn)小差錯(cuò)。

如果你非常熟悉Dubbo的調(diào)用過(guò)程，直接知道大概在這里

com.alibaba.dubbo.remoting.exchange.support.DefaultFuture#doReceived

我們打3個(gè)斷點(diǎn)：

斷點(diǎn)①為了證明我們的請(qǐng)求進(jìn)來(lái)了

斷點(diǎn)②為了證明進(jìn)了回調(diào)

斷點(diǎn)③為了能從接收到數(shù)據(jù)包的初始位置開始排查

按照我們的想法，執(zhí)行順序應(yīng)該是①、③、②，但是這里很奇怪，并沒(méi)有按照我們的預(yù)期執(zhí)行，而是先執(zhí)行①，再執(zhí)行②，最后執(zhí)行③！

這是為什么？對(duì)于排查問(wèn)題中的這些沒(méi)有符合預(yù)期的蛛絲馬跡，要特別留心，很可能就是一個(gè)突破點(diǎn)。

于是我們對(duì)asyncCall這個(gè)方法進(jìn)行跟蹤：

發(fā)現(xiàn)這里callable調(diào)用call返回了false，然后false不為null且不是CompletableFuture的實(shí)例，于是直接調(diào)用了CompletableFuture.completedFuture(o)。

看到這里估計(jì)有部分小伙伴發(fā)現(xiàn)了問(wèn)題，正常情況下，Dubbo的異步調(diào)用，執(zhí)行調(diào)用后，不會(huì)立馬得到結(jié)果，只會(huì)拿到一個(gè)null或者一個(gè)CompletableFuture，然后在回調(diào)方法中等待server端的返回。

這里的邏輯是如果返回的結(jié)果不為null且不為CompletableFuture的實(shí)例就直接將CompletableFuture設(shè)置為完成，立馬執(zhí)行回調(diào)。

暫且不管這個(gè)邏輯。

我們先看為什么會(huì)返回false。這里的callable是Dubbo生成的一個(gè)代理類，其實(shí)就是封裝了調(diào)用Provider的邏輯，有沒(méi)有辦法看看他封裝的邏輯呢？有！用arthas。

• arthas

我們下載安裝一個(gè)arthas，可以參考如下文檔：https://arthas.aliyun.com/doc/quick-start.html

attach到我們的Consumer進(jìn)程上，執(zhí)行sc命令（查看已加載的類）查看所有生成的代理類，由于我們的Demo就生成了一個(gè)，所以看起來(lái)很清晰

sc *.proxy0

再使用jad命令反編譯已加載的類：

jad org.apache.dubbo.common.bytecode.proxy0

看到這里估計(jì)小伙伴們又揭開了一層疑惑，this.handler.invoke就是去調(diào)用Provider，由于這里是異步調(diào)用，必然返回的是null，所以返回值定義為boolean的方法返回了false。

看到這里，估計(jì)小伙伴們對(duì)《Java開發(fā)手冊(cè)》里的規(guī)范有了更深的理解，這里的處理成false也是無(wú)奈之舉，不然難道返回true？屬于信息丟失了，無(wú)法區(qū)分是調(diào)用的返回還是其他異常情況。

我們?cè)倩仡^看asyncCall：

圈出來(lái)的這段代碼令人深思，尤其是最后一行，為啥直接將CompletableFuture設(shè)置為完成？

從這個(gè)方法的名字能看出它是執(zhí)行異步調(diào)用，但這里有行注釋：

//local invoke will return directly

首先這個(gè)注釋的格式上下不一，//之后講道理是需要一個(gè)空格的，我覺得這里提個(gè)PR改下代碼格式肯定能被接受~

其次local invoke，我理解應(yīng)該是injvm這種調(diào)用，為啥要特殊處理？這個(gè)處理直接就導(dǎo)致了返回基本類型的接口在異步調(diào)用時(shí)必然會(huì)返回false的BUG。

我們測(cè)試一下injvm的調(diào)用，將demo中injvm參數(shù)改為true，Consumer和Provider都在一個(gè)進(jìn)程中，果然和注釋說(shuō)的一樣：

server is user : true
client is user = true

如何修復(fù)

我覺得這應(yīng)該算是Dubbo的一個(gè)BUG，雖然這種寫法不提倡，但作為一款RPC框架，這個(gè)錯(cuò)誤還是不應(yīng)該。

修復(fù)的辦法就是在injvm分支這里加上判斷，如果是injvm調(diào)用還是保持現(xiàn)狀，如果不是injvm調(diào)用，直接忽略，走最后的return邏輯：

public <T> CompletableFuture<T> asyncCall(Callable<T> callable) {
    try {
        try {
            setAttachment(ASYNC_KEY, Boolean.TRUE.toString());
            final T o = callable.call();
            //local invoke will return directly
            if (o != null) {
                if (o instanceof CompletableFuture) {
                    return (CompletableFuture<T>) o;
                }
                if (injvm()) { // 偽代碼
                    return CompletableFuture.completedFuture(o);
                }
            } else {
                // The service has a normal sync method signature, should get future from RpcContext.
            }
        } catch (Exception e) {
            throw new RpcException(e);
        } finally {
            removeAttachment(ASYNC_KEY);
        }
    } catch (final RpcException e) {
        // ....
    }
    return ((CompletableFuture<T>) getContext().getFuture());
}

最后

排查過(guò)程中還搜索了github，但沒(méi)有什么發(fā)現(xiàn)，說(shuō)明這個(gè)BUG遇到的人很少，可能是大家用異步調(diào)用本來(lái)就很少，再加上返回基本類型就更少，所以也不奇怪。

而且最新的代碼這個(gè)BUG也還存在，所以你懂我意思吧？這也是個(gè)提交PR的好機(jī)會(huì)~

不過(guò)話說(shuō)回來(lái)，我們寫代碼最好還是要遵循規(guī)范，這些都是前人為我們總結(jié)的最佳實(shí)踐，如果不按規(guī)范來(lái)，可能就會(huì)有意想不到的問(wèn)題。

當(dāng)然遇到問(wèn)題也不要慌，代碼就在那躺著，工具也多，還怕搞不定嗎？