所以如果要确保key_t值不变， 要么确保ftok的文件不被删除，要么不用ftok，指定一个固定的key_t值。
如果存在生成key_t值的文件被删除过，则很有可能自己现在使用的共享内存key_t值会和另外一个进程的key_t值冲突，如下面这种情况：
进程1使用文件1来ftok生成了key10000，进程2使用文件2来ftok生成了key 11111，此时如果进程1和进程2都需要下载文件，并将文件的内容更新到共享内存，此时进程1和2都需要先下文件，再删掉之前的共享内存，再使用ftok生成新的key，再用这个key去申请新的共享内存来装载新的问题，但是可能文件2比较大，下载慢，而文件1比较小，下载比较慢，由于文件1和文件2都被修改，此时文件1所占用的文件节点号可能是文件2之前所占用的，此时如果下载的文件1的ftok生成的key为11111的话，就会和此时还没有是否11111这个key的进程2的共享内存冲突，导致出现问题。
解决方法：
方法一：
在有下载文件操作的程序中，对下载的文件使用ftok获取key的时候，需要进行冲突避免的措施，如使用独占的方式获取共享内存，如果不成功，则对key进行加一操作，再进行获取共享内存，一直到不会产生冲突为止。
方法二：
下载文件之前，将之前的文件进行mv一下，先“占”着这个文件节点号，防止其他共享内存申请key的时候获取到。
另外：
创建进程在通知其他进程挂接的时候，建议不使用ftok方式来获取Key，而使用文件或者进程间通信的方式告知。
共享内存删除的陷阱？
当进程结束使用共享内存区时，要通过函数 shmdt 断开与共享内存区的连接。该函数声明在 sys/shm.h 中，其原型如下：
#include
#include
int shmdt(const void *shmaddr);
参数 shmaddr 是 shmat 函数的返回值。
进程脱离共享内存区后，数据结构 shmid_ds 中的 shm_nattch 就会减 1 。但是共享段内存依然存在，只有 shm_attch 为 0 后，即没有任何进程再使用该共享内存区，共享内存区才在内核中被删除。一般来说，当一个进程终止时，它所附加的共享内存区都会自动脱离。
我们通过：
int shmctl( int shmid , int cmd , struct shmid_ds *buf );
来删除已经存在的共享内存。
第一个参数，shmid，是由shmget所返回的标记符。
第二个参数，cmd，是要执行的动作。他可以有三个值：
命令 描述
IPC_STAT 设置shmid_ds结构中的数据反射与共享内存相关联的值。
IPC_SET 如果进程有相应的权限，将与共享内存相关联的值设置为shmid_ds数据结构中所提供的值。
IPC_RMID 删除共享内存段。
