不要太相信别人的注释

         前几天接手了一个程序，需要在原来的基础上添加新的功能，具体如下：现有三个线程通过UDP分别接收音频流、音频流和视频流。需要在这个基础上添加新的功能，即要这三个线程也能够接收图片，接收的图片只能一个线程接收一张，不能由同一个线程接收。我认为这个应该是没什么问题的，只要将音频的缓冲区在接收图片时加大就可以了，结果显然跟我预期的不一样。代码改出来了，测试时发现只有接收视频流的那个线程能够收到数据，其他的两个线程无论怎么弄死活收不到数据，从数据抓包，到重新写个3线程的程序来模拟接收都证明数据发送 端确实把数据发出来了，是我这边程序的问题。三个线程的代码都看了好多遍都没看出什么端倪，本以为几个小时可以解决的问题10天都过去了（由一个线程接收所有数据，十分钟搞定，但是上面规定就是要一个线程收一张，是不是有点冥顽不灵？），一点进展都没有。跟上面反映说让我先看着，有时间帮我看看，我就等。今天早上来跟硬件的同事聊了点童年趣事就过来准备看代码了，我也没指望出现什么奇迹，就按照前面的思路再查一遍，我把两个线程的内容贴到了notepad++里面准备再对比一下他们的异同，在eclipse里面复制代码时不小心点到了对应的头文件，如下图所示：

，反正是做不出来了，就看看当消磨这段令人窒息的时间，看过这段代码之后才发现原来VideoBuf 和AudioBuf大小是不一样的，VideoBuf 为 100k+ ，AudioBuf 是 320+，然后突然想起看了不知多少遍的代码：

看到没，“接收缓冲区”注释下面的两句：int nRecvBufLen = sizeof(VideoBuf); //设置为32K   和 int nRecvBufLen = sizeof(AudioBuf); //设置为32K  注释都为32k 而实际上 sizeof(AudioBuf) 的返回值才320+，然后经过下面的setsockopt() 一设置就两个音频线程就不知不觉收不到数据了。当初检查代码看到这个注释看他们一样就没注意了，想不到竟然是被这一句注释给坑了，好了改成下面的版本：

编译之后程序成功运行：

现在知道了，千万别相信别人的注释，记下此文，以示警戒！！！！