做开发，永远都避免不了文件的读与写，当然也有删除。而读与写被大家挖掘的太多，对于文件的删除，却少有人注意，因为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，其实就可以避免很多这种隐形的问题，并且还能缓解服务器的压力。
相关文章
