int AbstractFile::OpenFile(const char* pathName, int oflag, mode_t mode)
{
m_fileID = open(pathName, oflag, mode);
if (m_fileID == -1)
{
m_fileID = 0;
// error message
perror("###########OPEN FILE Error,msg:");
return ERROR_OPEN_FILE;
}
return m_fileID;
}
---一下就定位出来出错的原因： too many open file
然后根据此文章
http://langyu.javaeye.com/blog/763247
运行在Linux系统上的Java程序可能会出现"Too many open files"的异常情况，且常见于高并发访问文件系统，多线程网络连接等场景。
程序经常访问的文件、socket在Linux中都是文件file，系统需要记录每个当前访问file的name、location、access authority等相关信息，这样的一个实体被称为file entry。“open files table”(图中橙色标识)存储这些file entry，以数组的形式线性管理。文件描述符(file descriptor)作为进程到open files table的指针，也就是open files table的下标索引，将每个进程与它所访问的文件关联起来了。
每个进程中都有一个file descriptor table管理当前进程所访问(open or create)的所有文件，文件描述符关联着open files table中文件的file entry。细节不表，对于open files table能容纳多少file entry。Linux系统配置open files table的文件限制，如果超过配置值，就会拒绝其它文件操作的请求，并抛出Too many open files异常。这种限制有系统级和用户级之分。
系统级：
系统级设置对所有用户有效。可通过两种方式查看系统最大文件限制
1 cat /proc/sys/fs/file-max
2 sysctl -a 查看结果中fs.file-max这项的配置数量
如果需要增加配置数量就修改/etc/sysctl.conf文件，配置fs.file-max属性，如果属性不存在就添加。
配置完成后使用sysctl -p来通知系统启用这项配置
用户级：
Linux限制每个登录用户的可连接文件数。可通过 ulimit -n来查看当前有效设置。如果想修改这个值就使用 ulimit -n <setting number> 命令。
对于文件描述符增加的比例，资料推荐是以2的幂次为参考。如当前文件描述符数量是1024，可增加到2048，如果不够，可设置到4096，依此类推。
在出现Too many open files问题后，首先得找出主要原因。最大的可能是打开的文件或是socket没有正常关闭。为了定位问题是否由Java进程引起，通过Java进程号查看当前进程占用文件描述符情况：
Java代码
- lsof -p $java_pid 每个文件描述符的具体属性
- lsof -p $java_pid | wc -l 当前Java进程file descriptor table中FD的总量
分析命令的结果，可判断问题是否由非正常释放资源所引起。
我通过命令获得用户级别的话，是1024个文件。然后采用ps -d 获得dataManage这个进程的id号比如是3626，lsof -p 3626|more来查看它操作了哪些文件。lsof -p 3626|wc -l 来统计其操作的文件的个数。发现有一个很特殊的文件叫 (null)/MemInfo.txt在不断的增长，果然，当它增长到1024的时，插入图片就出错了。之后也不再进行图片数据的操作。
原因就在这里了，那：为什么会产生MemInfo.txt这个空文件呢？？？
而且 MemInfo.txt 其完整路径是 (null)\MemInfo.txt，这是一个空路径，我无法在代码里面找到关于它的任何信息。用find path filename 也找不到文件。
于是怀疑是调用的lib库产生问题，采用如下命令
/usr/lib
然后使用 /usr/lib/ |xargs grep MemInfo.txt
提示： Binary file /usr/lib/libGGG_HR_PR.so matches
ok，只需要调用lib对应的测试程序，就可以校验是不是那个问题了。