java如何判断Linux系统文件是否被占用

我没明白你的意思，你的意思是你有两端，server和client，client端是window，你用是否可以修改名字来判断是否上传完成，server端是linux，你不知道如何判断这个文件是否上传完成，所以你想问问解决办法是把？
如果是这样的话：
在上传文件完后，再上传一个MD5文件（完整文件名+文件MD5值）。
检查此MD5文件是否存在，并且MD5值是否正确，即可判断，之后删除MD5

文件，当然了方法很多，比如获取FTP中上传文件的大小，之后对比下就好了

原因如下：
1、你所要传的文件已经被打开。被打开的文件是传输不了的，请把它关闭。
2、你所要传的文件虽然已经关闭，但是还没有完全退出程序，或者相关的文件还在运行。请打开任务管理器，把相关的进程都结束。
3、以上两个步骤都解决不了的话，请关机重启电脑，把要传输的文件打开看看是否完好，打包一下（压缩解压）再传。

背景
最近一直收到产品环境其中一台server的磁盘占用超过90%的警告，之前为了解决这个问题编写了一个压缩和删除历史log的脚本，正常情况来说应该不会再报这个警告，因为脚本是每天都在跑，所以每天增长的log的大小应该不至于占用很多的磁盘空间，但是实际情况却是每隔两三天就会收到一次警告，然后不得不手动的清理一些还没有被脚本压缩以及删除的log，从而释放一些空间，但是这不是长久之计，所以就详细的去查了这个问题。
解决
再次受到这个警告之后，我通过SSH连到了这台机器，然后通过df -h的命令查看了一下各个挂载磁盘的使用率如下图：

从图中可以看到可以看到 /dev/xvdb1这个磁盘被挂载在/alidata1/这个目录下，并且已经使用了34G(90%)
然后就要查看/alidata1下到底是哪个文件或者文件夹占用了这么多的磁盘空间，我们通过du -h --max-depth=1来查看，如下图：

我们可以看到 /alidata1下的所有文件及文件夹占用的空间是22G，和我们通过df -h查看出来的磁盘占用34G相差12G，这是为什么？这12G的空间到底是被谁占用了？
于是去网上查了一些资料，原来是因为在Linux上删除一个进程正在写入的文件的时候，虽然已经被我们删除了，但是只要进程还在，那个文件就不会真正被删除，只是被临时存放到系统的某个地方，有点类似于Windows的回收站。通过lsof可以查看没有被真正删除的文件。如下图

从图中我们可以看出有四个占用空间比较大的没有被真正删除的文件，这四个文件分别是809和808的java进程console的输出log。之前被手动删除，但是由于没有重启进程导致文件一直还在，占用了大量空间。在通过重启808和809的java进程之后，磁盘的警告恢复了，通过df和du查看的结果如下：
df -h

从新的结果中可以看到df查看的磁盘占用空间和du查看的文件中下文件的占用空间一致了。
总结
所以如果以后碰到一些不合理的一些磁盘占用情况，我们可以通过df和du来查看磁盘占用空间和实际的文件占用空间是否有差异，如果有差异通过lsof命令查看有哪些没有被真正删除的文件，确认是被哪个进程占用，通过重启进程的方式来释放这些空间。

这个问题需要在具体的情况下进行分析，因为不同的文件在不同的进程中被占用的原因可能不同。在macOS中，有一个叫做`lsof`的命令可以帮助我们查看文件被哪个进程占用。你可以在终端中输入以下命令来查看：
```
lsof | grep include
```
这个命令会列出当前所有被打开的文件，并查找包含`include`字符的文件。如果你已经知道具体的文件名，可以将`include`替换为文件名进行查找。
当文件被占用时，可能有以下几种原因：
1 文件被其他程序占用。例如，某个应用程序正在使用该文件，或者该文件被其他用户占用。
2 文件正在被读取或写入。例如，某个程序正在读取或写入该文件，导致其他程序无法访问该文件。
3 文件被锁定。如果一个程序锁定了该文件，其他程序将无法访问该文件，直到锁被释放。
如果文件被占用，我们可以通过查找占用该文件的进程，来找出问题的根源，并采取相应的措施解决问题。

客户端这边的output对象要关闭，然后清空缓存区域
outflush();
outclose();
你要注意是不是在客户端监听那个方法里面没有释放文件输入流对象。所以才一直占用。
我觉得出现你这样的问题是因为你socket传输规则有问题。没有提示程序是否接收完毕，所以客户端会一直卡在read方法那里。接收回来的文件对象也没有释放，建议socket传输规则 [文件长度|文件内容] 就是说先接收前面4（你自己定义的）个字节获取整个流的长度。然后在接着读流，这个长度读完了，说明文件接收完。就跳出循环结束接收数据。

---