PJM 软件数据结构方面组织的还是不错的；
typedef struct PjmsPktHeader {
int msgcode; /*!
int errcode; /*!
int16_t rscunit_id; /*!
int16_t reserved[3]; /*!
struct timespec send_date; /*!
struct timespec recv_date; /*!
ssize_t data_size; /*!
uint64_t data[0]; /*!
} PjmsPktHeader_t;
里面的data种类多了；
PjmsPktHeader_t *pktdata_p
PjmsReqJobStart_t *job_start_p = NULL;
job_start_p = (PjmsReqJobStart_t *)pktdata_p->data;
typedef struct PjmsReqJobStart {
RmSjid_t subjobid; /*!
uint32_t job_type; /*!
int32_t reserved; /*!
PjmsVparam_t vparam; /*!
PjmsExecUnit_t execunit; /*!
int num_fshare; /*!
int32_t num_gionode; /*!
off_t fshare_off; /*!
off_t gionode_list_off; /*!
} PjmsReqJobStart_t;
这样的话，有几个好处：（注意：其中1的好处是靠FJ那边能实现个功能，即把结构体里的off_t变量指向的内存空间都释放了，只有这个功能实现了，才能谈得上正确的内存释放）
1：释放内存操作很简便的，直接释放pktdata_p就行了，后面的PjmsReqJobStart_t 结构体以及它附带的一些结构体内存分配（靠off_t实现的）可以被跟随着就释放了，从而避免担心内存泄露问题；
2：统一的 头格式PjmsPktHeader_t
3：利用off_t 形式可以将紧跟着PjmsReqJobStart_t后面的内存分配空间跟PjmsReqJobStart_t中的off型变量连接在一块，通过该off型变量就可以直接引用到PjmsReqJobStart_t后面的内存分配空间中的东西
4：这种结构体后带有后缀内存分配区域形式可以使内存利用更加紧凑；
5：PJMD和PJSD的通信就是这些数据包的传递来进行的，而这些数据包利用完后，又可以及时的释放，从而回收了内存，利用数据包的传递来进行PJSD的工作，也可以避免在PJSD中的零散小内存泄露
内存泄露现象怎么避免，有时感觉是架构设计方面的问题；
比如在running_exec函数及其调用子函数中
是两个数据在流动的，target_p 和 PjmsPktHeader_t型数据
靠这两个数据的流动，来完成函数主要功能和避免内存泄露（因为释放内存只要考虑着这两个数据就行了）
内存泄露可以通过集中数据的通信流来避免，就是不要随意的calloc出独立（要calloc出和其他结构体相关联的内存空间）的内存空间，通过将内存分配集中到几个主要数据结构体，并靠着这几大数据结构体来完成PJSD的主要功能，通过这种形式来避免内存泄露现象发生
虽然黑体部分的现象发现的晚，但感觉靠着数据通信的相互作用来促使完成PJSD功能的办法，是能够避免内存泄露的。
PJM软件的内存泄露主要集中在off_t型的变量没办法释放这一块。
又看了一遍，感觉那个黑体部分是不会出现内存泄露问题，因为
Free的原型是这样的：
void free(void *ptr);
void *calloc(size_t nmemb, size_t size);
void *malloc(size_t size);
所以黑体部分的担心是多余的，所以PJM软件的这种数据结构组织还是不错的
上 查了查malloc函数的实现，搜到信息说如果用malloc分配的空间size这个值为2的整数倍的话，就会以后malloc的内存分配速度会大大加快，真的如此吗，还有待考证
文章知识点与官方知识档案匹配，可进一步学习相关知识算法技能树首页概览34382 人正在系统学习中
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！