java 文件删除不成功

做开发，永远都避免不了文件的读与写，当然也有删除。而读与写被大家挖掘的太多，对于文件的删除，却少有人注意，因为File类中有delete()方法。

其实仔细看，会发现这个方法并不是void的返回类型，而是boolean的true和false。

那Java为何要把这个方法的返回类型设置为boolean呢？

那不外乎就是告诉我们文件是否有被删除掉。

那我也能这样理解，我要删除的文件，可能不会被删除掉。

当然，这个可能性很小，但对于java来说，哪怕可能性近乎为0，也总是有人品好的能够碰到...

 

在做文件上传，我表单提交的时候，如果文件不符合或文件中的内容不符合，就会出现回滚的情况。

那除了要回滚数据库中已经保存的数据，还要回滚掉已经上传的文件。

 

在我们本地测试的时候，永远只有我们自己在测试，不良好的编程习惯除了浪费掉更多的资源外，也让我们忽略掉会出现的问题，而File.delete()就是很典型的例子。

 

要使用File.delete就可能要设计到这个文件是否被占用，也许我们并没有打开这个文件，但是，在这个文件被上传的时候，总是会有一个流的。这个流就有可能占用这个文件，导致这个文件不会被删掉。

 

那也许会有人疑惑，在上传完毕的时候，这个流我已经close掉了。

但对于java不然，其实，已经有人说过流的close问题了，它同System.gc()一样，只是告诉java要去清理，但什么时候去执行这个动作， 永远要看jvm的心情。

流的close也同样如此，我们永远不能保证这个文件的流已经被jvm给关闭了。（当然，大部分情况都是很及时的关闭的）。

 

那对于这种情况，刚开始的感觉好像就是束手无策了。

我都已经close了，但jvm自己不去关闭，那我也没办法。

其实，这个时候，就要体现system.gc()的用途。

在file.delete()之前，先执行system.gc()，能够很顺利的去删除掉文件，并且不会碰到删不掉的问题，哪怕它是个压缩文件。

 

很奇怪对吧，system.gc()也是延迟执行的，那这个时候它就不是延迟执行了。

这也许就是java的魅力吧....

当然，其实真正原因还是在于个人编码的良好习惯。

如果养成在每个方法结束的时候，把方法体中的对象等参数设置为null，其实就可以避免很多这种隐形的问题，并且还能缓解服务器的压力。