多线程的坑，不要用sleep

找了一周的bug，终于发现了是哪里导致了问题出现。
最开始40路推流时候一切的正常，但随着长时间的工作后发现画面变卡了，打印相关信息，发现buf偶尔会多起来。
开始了漫长了调试，一开始以为线程数量不够，然后增加了几个线程。但是问题还是没有解决，于是我将sleep 改小了。随之而来的是cpu的上涨，但是问题还是没有解决。
最后我将sleep换成了锁的机制。发现问题好很多，虽然还是会出现，不过能够随着时间又变回去。最后我发现线程里有个十分耗时的操作，一旦40路同时工作时候，线程就会应付不了，从而导致了卡顿的出现。
真不应该一开始用了sleep，不然就不会出现许多奇怪的问题，而且优化的时间比起开发更长。最后来一段伪代码来分析一下，但不能百分百保证，至少是我自己的一个思考。

while(1)
{
lock()
/*临界资源*/
unlock()
/*do something*/
/*因为要等待资源，所以就睡上100us了*/
 sleep(100);
}

上面的代码里，如果你用多个线程工作，而且do something是不会有线程冲突的话，一般是没有问题。但如果是很高的并发资源来了，那么问题就会出现了。
首先lock锁住了资源，这样的话，一旦大量资源来了，就在这出现问题。这里就是瓶颈之处。解决方法我想到的是再将资源分类，那样用trylock的方式能够解决。
第二个问题就是这次要说的sleep了，如果在sleep时候，突然大量资源来了，那么就会出现一个问题了，线程不足以应付问题。而且就算你将线程数量增多，这只是从一定程度上解决。
最好的方式是应该利用锁，一来资源就解锁。那样比起sleep好很多。但上锁也会出现问题呢？那你要设立一些检测条件上去，没有资源就锁。有资源让他自己去跑吧。