找了一周的bug,终于发现了是哪里导致了问题出现。
最开始40路推流时候一切的正常,但随着长时间的工作后发现画面变卡了,打印相关信息,发现buf偶尔会多起来。
开始了漫长了调试,一开始以为线程数量不够,然后增加了几个线程。但是问题还是没有解决,于是我将sleep 改小了。随之而来的是cpu的上涨,但是问题还是没有解决。
最后我将sleep换成了锁的机制。发现问题好很多,虽然还是会出现,不过能够随着时间又变回去。最后我发现线程里有个十分耗时的操作,一旦40路同时工作时候,线程就会应付不了,从而导致了卡顿的出现。
真不应该一开始用了sleep,不然就不会出现许多奇怪的问题,而且优化的时间比起开发更长。最后来一段伪代码来分析一下,但不能百分百保证,至少是我自己的一个思考。
while(1)
{
lock()
unlock()
sleep(100);
}
上面的代码里,如果你用多个线程工作,而且do something是不会有线程冲突的话,一般是没有问题。但如果是很高的并发资源来了,那么问题就会出现了。
首先lock锁住了资源,这样的话,一旦大量资源来了,就在这出现问题。这里就是瓶颈之处。解决方法我想到的是再将资源分类,那样用trylock的方式能够解决。
第二个问题就是这次要说的sleep了,如果在sleep时候,突然大量资源来了,那么就会出现一个问题了,线程不足以应付问题。而且就算你将线程数量增多,这只是从一定程度上解决。
最好的方式是应该利用锁,一来资源就解锁。那样比起sleep好很多。但上锁也会出现问题呢?那你要设立一些检测条件上去,没有资源就锁。有资源让他自己去跑吧。