这两天碰到一个奇怪的case。
场景：
在下载文件的过程中，停止下载，删除文件，接着重新下载。（文件的地址是一样的，文件越大越容易复现）
问题：
虽然删除了文件，delete方法返回的也是true，看目录发现文件确实被删除了，但是通过无限循环发现，文件对应的内存空间没有被释放掉。
解决：
通过断点发现，底层下载文件的库在停止下载的时候先删除文件，后关闭流。这个顺序有问题，所以导致了delete的虽然返回了true，但实际上文件的流还没有关闭，所以文件所在的空间并没有释放。如果这时候再创建文件就会抛异常。
更新：
经过仔细阅读底层下载库，发现还有一个问题，使用了MappedByteBuffer去写入文件，这个类是nio中的，他只有 map方法，没有unmap方法，导致空间只能在gc的时候释放。这个类在我们目前的业务使用不太合适，所以改为传统的io操作。
详细解释可以参考：
