linux编程的一些教训

本文主要是介绍linux编程的一些教训，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

初学linux平台上的C编程时间不长，这次正好有一个业务项目需要用到队列，研究和对比了一下市面上的相关产品，总体而言不是太复杂就是性能达不到要求，所以最后还是决定自己写一个。这次用C完完全全由自己实现只是第二次，以前都是下个开源软件改一下，一般来说linux下的软件只要是C开发的，性能都可以接受。但是为了……，还是自己决定写一下。在整个开发过程中，碰到的血泪教训太多了，这里先记录一下，第一：警示自己，以后不要再犯了；第二：给有用的人分享一下，别人跳过的坑尽量避免自己再跳（好像我经常会跳？？嘻嘻）！

    1.内存泄漏；这是一个老问题了，这次开发的mq使用到了tc服务器接口，本着小心的态度，我几乎每个malloc的对象都会尽快释放，并且写到malloc的时候就紧张，一定要在这个函数中查看一下，是否把malloc的对象都free了。但是tc还是把我害死了，因为用到了从tc中取值的get函数，结果这个函数返回的值需要有开发人员自己free掉的，结果……，后来导致内存错乱才发现了错误。引起这个问题的原因是没有仔细看tc的文档，咳，杯具。

   2.指针参数：这个问题也可以归结为内存泄漏。对于malloc的变量，free之后一定要置为NULL,这样我们就可以通过判断这个自增是否为NULL来编程。所以为了简单和不至于忘记最后的一个置NULL操作，我把这个过程写成了函数：

     void mem_free(void *ptr)

     {

          if(NULL != ptr)

         {

               free(ptr);

               ptr = NULL;

        }

     }

不仔细看没发现问题吧，把ptr的指针free掉，然后NULL操作，但是问题来了，当我为char *buff 执行mem_free(buff)函数后，发现第二次运行mem_free(buff)发现NULL ！= ptr竟然为true，郁闷了吧？这个问题搞了我半天时间，后来查看相关书籍才发现，当第一次mem_free的时候，free确实把内存给清除了，但是坏就坏在ptr = NULL；上，注意这个时候ptr只是一个指向buff指针的副本，也就是这个时候运行时态的指针可以理解成这样ptr->buff->heap，free是因为没有改变ptr的指向，只是free掉了值，所以heap中的值被清除了，但是ptr = NULL，其实是切断了ptr –> buff的这根链，那么，buff ->heap这个链没有断开，所以其实buff还是指向这heap这个内存，虽然heap中已经不存在任何有用的数据了。但是我们的本意是要断开buff –> heap这个链，所以这个函数应该写成传递二级指针：

     void mem_free(void **ptr)

     {

          if(NULL != *ptr)

         {

               free(*ptr);

               *ptr = NULL;

        }

     }

这个问题可以总结为：改变指针指向的内容不需要传递指针地址，改变指针的指向，一定要传递指针的地址。

   3.字符串（或者是字符数组，一下称字符串）结束符。对于字符串结束符很多人都没有搞明白，包括之前的我。每个字符串都会在最后加上一个’\0’结束符，以示这个字符串结束了，如果人为手工没补齐，那么自动补齐。我的经验就是不管什么时候（声明char *buff = “i am chinese.”这种时候除外），特别是执行了strcpy或者memcpy后，如果你copy的是字符串，那么一定要手工上去补齐一下，当然，如果你memcpy的是二进制内存，那句不需要补齐了。

    4.内存补齐。这个问题困惑了我2天。比如有一个结构体：

     typedef  struct header_type

     {

         char protocol;

         int state;

         int64_t bodylen;

     } header_t;

    那么 sizeof(header_t)和sizeof(char) + sizeof(int)+sizeof(int64_t)这两者的值一样吗？答案是不一样的。不要说自己看错了，我确定是不一样的，至少在我机器上是不一样的。前者在我机器上的值为16，后者加起来为13.原因就是内存补齐。对于c而言，在申请的内存的时候会启用内存补齐，补齐规则有的定死了，有的可以调整，具体需要看cpu和编译器。在我的机器上是2^n规则，1，2，4，8，16…….所以长度为13的补齐后就是16了。那么如果在同一机器上，这点可以忽略，但是如果你要通过网络传递这个结构体，那你就不能忽略这个了。原因有二：如果你直接传递这个结构体的变量，那么需要考虑网络字节序和内存大小端，这个太麻烦，放弃，第二：不考虑原因一的变通方法是全部使用char *传递。那么如果你使用sizeof（header_t）申请内存，这个时候客户端接收到buff传递的值是16位的，最后的3位其实是无用的，但是客户端并不知道，所以会引起内存混乱。解决办法就是申请char *buff内存的时候，长度要是真正的内存大小，不要把内存对齐的空隙加入进去。但是你使用malloc给headet_t的对象申请内存时要使用sizeof（header_t），因为不使用sizeof的话就会出现内存溢出。

  5.recv的时候不管是不是non-block模式，都需要判断是否超时。我就碰到这个问题，设置了timeout后，没有判断超时，客户端接收到服务器返回的结果非常的不稳定，一会儿好的（在超时时间内返回），一会儿又都是乱码。后来发现原来recv返回-1了，并且errno置为11了。解决了这个问题后就不会出现接收不到数据的情况了。

   6.字节长度：因为问题5的出现，导致了我怀疑服务器端的数据传输问题，所以就增加了打印header_t的buff的想法，但是这个buff是一个二进制，直接打印二进制不行，只能转换到16进制，然后打印。所以加入了以下代码；

   char header_buff[14];

    bin2hex(buff,13,header_buff);

    log(header_buff);

   结果程序每次运行到这里的时候就会引发系统abort的信号。开始找不到原来。后来经人指点，发现header_buff申请的空间错了。header_t的二进制长度为13，但是每个字节16进制表示需要2个字节，所以13个二进制字节需要26个字节（有点绕口），再加上一个字符串的结束符，所以应该申请的是27个字符。

这篇关于linux编程的一些教训的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---