在频繁调用的底层函数中使用malloc的影响分析_频繁malloc free的问题

近来，测试中发现一个问题，ipcam会自动重启。经过定位，是增加了一个外部i2c timer作为看门狗引起的。
看了ex-wdt keep alive的code后发现，调用了一个i2c_WriteBytes()函数，这个Func中调用了两次malloc申请内存，并且，对malloc分配的
指针未作NULL的检查。我认为问题就出在这里，原因是这样：
1、虽然在这个Func中，malloc与free是配对使用的，但是，在一个多任务的环境中，这个Func可能被抢占，也就是说，先malloc后，接着是
其它进程去malloc，因此，malloc申请小的内存，仍然可能导致碎片化及整理内存的开销日益增大。这与测试中发现的现象可以吻合。
首先，测试中发现ipcam在重启前变得越来越慢，这是整理内存开销越来越大导致的，malloc/free执行时间会变得很长。其次，用两个进程来
keep ex-wdt alive，结果ipcam重启变得更频繁了，一晚上16台有6台重启。这是因为调用i2c_WriteBytes()函数变得更加频繁，压力之下加
速了该问题的发生。
2、对malloc申请的指针不作检查，如果不幸申请到null指针直接使用，同时有送进内核使用。这必然导致linux kernel crash，进而导致
watchdog复位。

针对上面的分析，可以用下面的方法进行验证：
1、压力测试：每秒feed一次ex-wdt，启动N个（N=10）进程来keep ex-wdt alive。其它进程仍然全部启动。
预期结果：几小时内出现CPU占用率不断升高，然后内核crash，进而watchdog复位。
2、对比测试：驱动函数取消malloc/free，同样进行压力测试。
预期结果：CPU占用率不会持续升高，内核不会crash并导致watchdog复位。