众所周知，日志是排查问题的重要手段。关于日志设计，以及怎么根据从【用户报障】环节开始到秒级定位问题这个我们下一期说（绝非套路），这一期，主要讲一下，在没有异常日志的情况下，如何定位问题。没有日志当真能排查问题，不会是标题党吧！

案例一

从最大的同性交友网站中拉取【dubbo-spring-boot-project】的代码。

然后把demo跑起来。

本场景是由真实案例改编，因为公司代码比较复杂也不方便透露，而这个demo在github上大家都能找到，既保证了原汁原味，又能让大家方便自己体验排查过程。

好了，我们先设置owner = "feichao",然后看一下控制台

一切正常

那么，当我设置成owner = "feichaozhenshuai!",再启动

看似一切都正常，那么，我们到控制台一看。

什么情况，怎么就没owner了？

这是在哪个环节出问题了？其实肥朝当初在公司遇到这个问题的时候，场景比这个复杂得多。因为公司的业务里没有owner的话，在运行时会出现一些其他异常，涉及公司业务这里就不展开了，我们言归正传，为毛我设置成feichaozhenshuai!就不行了，那我设置成肥朝大帅比电脑会不会爆炸啊？？？

常见的错误做法是，把这个问题截图往群里一丢，问“你们有没有遇到过dubbo里面，owner设置不生效的问题？”

那么有人会这么问，“dubbo里面设置owner却不生效，你们觉得我要从个角度排查问题？”。一看到这么正确的提问方式，我觉得我不回复你都不好意思。好了，回到主题，这个时候，没有一点点错误日志，但是却设置不成功，我们有哪些排查手段？

套路一

直接找set方法，看看是不是代码做了判断,防止在owner字段里面set类似肥朝真帅这种词语，避免把帅这件事走漏风声!。这么一分析似乎挺有道理对吧，那么，如何快速找到这个set方法呢？如图

public void setOwner(String owner) {
    checkMultiName("owner", owner);
    this.owner = owner;
}

我们跟进checkMultiName代码后发现

protected static void checkProperty(String property, String value, int maxlength, Pattern pattern) {
    if (StringUtils.isEmpty(value)) {
        return;
    }
    if (value.length() > maxlength) {
        throw new IllegalStateException("Invalid " + property + "="" + value + "" is longer than " + maxlength);
    }
    if (pattern != null) {
        Matcher matcher = pattern.matcher(value);
        if (!matcher.matches()) {
            throw new IllegalStateException("Invalid " + property + "="" + value + "" contains illegal " +
                    "character, only digit, letter, '-', '_' or '.' is legal.");
        }
    }
}

从异常描述就很明显可以看出，原来owner里面是只支持-和_等这类特殊符号，!是不支持的，所以设置成不成功，和肥朝帅不帅是没关系的，和后面的!是有关系的。

套路二

我们知道idea里面有很多好用的功能，比如肥朝之前的【看源码，我为什么推荐IDEA?】中就提到了条件断点，除此之外，还有一个被大家低估的功能，叫做异常断点。

里面的单词都是小学的英语单词，因此怎么使用就不做过多解释。遇到这个问题时，我们可以这样设置异常断点。

运行起来如下：

这样，运行起来的时候，就会迅速定位到异常位置。然后一顿分析，应该很容易找出问题。

是不是有点感觉了？那我们再来一个题型练习一下。

什么是编程思想？

肥朝始终觉得，要想比别人更优秀，除了比别人更努力这个必要因素外，思维方式，也是我们必要关注的一个重点。比如在案例二中，很多同学知道了bug之后，就认为自己学到东西了，其实这个想法既正确，也不正确。

正确的地方在于，你知道了这个bug，后面遇到相同的问题，你会猜一下是不是同样的原因。

不正确的地方在于，你只知道了这个bug出现的某个场景，但是当我们遇到这个问题，应对的排查套路有哪些你并不知道。也就是说，如果这个问题过后，你排查问题的套路并没有增加，亦或者你没有能从这个问题上，发散出自己的想法，继续压榨出更多的价值，本质上，你的编程能力，其实并没有提升的。

然而，你一旦在公司时间长了，也就是我们常说的老油条，对公司的某些坑熟悉，新人遇到问题时，就容易猜对可能是某个坑。但是其实你的套路来来去去就那几个，本质上你的编程能力并没有提升，却让你产生了自己越来越牛逼，这下必须要加薪的错觉。

一个公司总是有线上报障是有问题的，但是一直不出问题也有问题的。当然很多时候，排查的机会或许轮不到你。这个时候，就会有常见的几种做法。

1.公司确实项目太简单，基本没有什么拿得出手的bug，都是一些低级的漏掉配置的bug。

2.大佬们在排查，反正不是我的问题，那我就看群吹吹水，下班美滋滋。

3.大佬们在排查，等他们有结论了，我就过去问一句是啥问题，然后暗自记下来，自己也涨点排查经验，Get到技巧，美滋滋。

4.大佬们在排查，得知原因后，深入思考，大佬们为啥会想到是这个原因，他们是怎么排查的？用了哪些排查工具？排查技巧？然后暗自总结一波，并把自己代入场景，脑补一下自己来排查问题，并把这个bug压榨出更多价值！（怎么压榨出更多价值，可以查看肥朝之前的源码实战文章，每一篇都有一个环节专门讲拓展思考的）

你的思维方式，你的行动，往往就决定你成为什么样的人。肥朝也始终相信，时间在哪，行动在哪，成就就在哪。一起共勉。

本文转自互联网，侵删