今天遇到 了 一个 STP的问题，从测试 现象 来看与之前一个FR的验证过程中表现出来的特征很相似。这种相似性将我引入了一种歧途：怀疑原来的修改有问题。
假设你知道第N次修改有潜在的case无法验证。那么这种潜在的风险，会让你下次遇到问题 时，不断的怀疑。
可能出问题的地方，一定会出问题，这是软件开发中的铁律。
因此，在发现问题N的 时候，解决方案一定要是闭环的。无懈可击的。对于不理解的点，一定要搞清楚。决不能放过任何疑点和偶然性。这样在下次出现问题时，才能将全部精力集中在已有现象的分析上。
潜在问题描述：在收到STP对端端口发送的TC变化通知时，启动一个Timer去清除已经学习到的MAC地址。然后在这个timer里，遍历这个instance所有vlan，并清除该vlan上的mac。
1）不理解的点，TC通知的次数是多少，间隔是多少。
2）在这个间隔时间内，Timer是否可以完成清MAC的操作；
我当时的做法：
上面两个点都不确定的情况下，假设TC通知次数不止一次,Timer 完成不了这些MAC的清除。然后以这个假设作为前提，去写对应的程序。上面这些假设应该是符合实际情况的。
于是，在Timer里的处理是---清一个vlan上的mac，并假设这个动作是个原子操作。即肯定可以在下次TC到达前完成。完成这个动作以后，再起一个timer去清除该instance上的下一个vlan上学习到的MAC。即在timer里面又启动了一个timer。这种timer嵌套timer的机制和方法并不清楚是怎么回事。这个是引起不确定性的又一个来源。这样就会破坏上面说的那种原子操作。这到底会发生什么，自己并不清楚。即在timer未开始执行和正在执行的过程中，release这个timer到底会发生什么，是未知 的。这些未知就会让自己陷入一种恐惧和焦虑之中。久而久之，会让自己对于编程失去热情。
老大指导说，对于不确定的地方，可以加打印去验证，加统计，用debug的手段去确定。然后再继续。
另外，可能出现问题的地方要加好trace和debug手段。以在下次真出现问题的时候，能够迅速的找到原因。这也是一种防范上面疑问的策略。最后，找到了这个新问题的root cause，与清mac没有任何关系，清mac不完全只是一个现象，这个现象还不能完全说明Timer机制出现了问题。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
