很多简单的Bug在公司内部测不出来，一上线立马就能被发现呢？其实，说到底，其实就是看程序员在写代码的时候是否细心，测试是否能考虑到。

(资料图)

低级Bug

举个例子，我们公司有个工作了比较久的研发同事，下面就叫他老张吧。他在写一段代码的时候在公司内部测试的时候就没被发现。大家都以为项目没问题了，结果项目一上线，不久就出了问题！

后来，根据Bug出现的轨迹，总算找到了问题出现的原因。按道理说，公司不是不容忍出现Bug，但是老张写的代码里犯了一个他这个工作经验不该犯的错误，那就是使用全局变量来计数时，并没有对全局变量进行加锁限制访问！

先简单说下功能，其实就是有个接口是盘点数据的功能，需要查询大量数据，并且从数据库层面暂时无法再进行优化，所以，公司在设计这个功能的时候，采取的是排队机制，同时使用该功能的人不能超过2个人。当超过2个人去调用的时候，这时候代码会返回让其等待的提示。

按道理讲，老张的做法是没错的，使用一个全局变量来计数，当访问接口的时候，先判断正在使用接口的人数，如果超过2个人，则直接返回消息，告知用户需要等待。

老张的代码逻辑是没有多大问题的，问题就在于他没有对计数的变量进行加锁！

这个问题之所以在内部没有被测出来，是因为测试只有一个人，并且，也没有并发测试的概念，因此代码在老张自己那里过了关，在测试那里也过了关！

项目上线不久，客户总是反映有软件经常卡死。然后我们公司运维通过分析软件日志，觉得软件经常卡死的原因是因为程序在对某张数据表在查询数据的时候经常要等很久，而查询是单线程查询的，所以软件会“假死”。但是，分析了查询语句以后，把查询语句直接放到数据库里去执行，发现查询结果很快就出来了。看来，问题似乎不是出在这个语句上，但是这位运维很有经验，他很快就知道了问题可能出现的原因。

然后，他告诉客户，下次出现这样的问题，要第一时间告诉他。

不久之后，客户说问题又出现了，于是运维赶忙去查看了下数据库进程，发现有一个数据库查询语句被卡在进程里好几分钟都没执行完，也就是我们说的锁表语句。一看之下，关联的正是之前分析的那张数据表。

通过分析这个查找到的锁表语句，很快就定位到了具体的功能，正是老张写的那个功能，老张一拍脑袋，发现自己犯了一个天大的错误。

研发总监看到问题解决了，也很好奇问题是怎么出现的，老张觉得不好意思支支吾吾地给他解释问题出现的原因。

研发总监听完老张的解释以后，自然很生气。

经过分析，我们还原了下客户数据库经常被锁表的原因。

老张写的代码里面，查询语句是有点慢的，一般要几秒才能执行完。但是，老张虽然加了访问控制的代码，可因为没有对全局计数变量进行锁定，导致并发量大的时候，还是有很大概率导致计数判断失效的！

因为查询比较慢，客户有时候急，就会连续点前端的功能按钮，导致了有数个线程访问接口，并发访问一大，查询语句就直接被锁死了！

结果

研发总监很纳闷，按说老张算是老程序员了，不应该犯这种低级错误，于是就一直问老张是怎么想的。

老张也解释不了自己为什么这么写，最后干脆两个人都笑了起来。研发总监被老张给气笑了，老张被自己的疏忽给蠢笑了！

老张能怎么解释？可能当时写代码的时候有别的事情分了心，其实说白了就是疏忽导致的。