Windows NFS共享下移动未完成写入文件致损坏的问题咨询

核心疑问解答 #

1. NFS写入未自动加锁的原因、Java对fcntl锁的支持说明 #

NFSv3的文件锁依赖独立的NLM（网络锁管理器，即你提到的nlockmgr）服务实现，跨平台兼容性极差，Windows作为NFS服务端时，默认不会将Unix客户端发起的fcntl锁映射为Windows本地的NTFS排他锁，所以才会出现Java侧加锁不生效的情况。
Java的FileChannel.lock()API底层直接调用操作系统的fcntl锁接口，本身是完全支持fcntl锁特性的，你遇到的锁无响应问题是Windows NFS服务端的兼容性缺陷导致，和Java本身无关。

2. PowerShell Copy命令的锁行为说明 #

PowerShell的Copy-Item不会自动为目标文件加排他锁，它底层调用的Win32文件API默认采用共享读写模式打开文件，复制过程中其他进程完全可以读取、修改未完成复制的文件，确实存在明显的时间窗口风险，用Copy替代Move不仅解决不了现有问题，还会引入新的竞争。

3. JVM无法被kill -KILL终止的原因 #

当nlockmgr无响应时，Java发起的锁请求会卡在**内核态不可中断睡眠（D状态）**的系统调用上，Linux内核设计中处于D状态的进程/线程不会响应任何终止信号，这是操作系统层面的特性，并非Java的缺陷，所有进程触发这类不可中断系统调用时都会出现相同现象。

可落地的无锁解决方案 #

依赖固定等待时间的方案没有绝对可靠性，也不需要强行解决NFS锁的兼容性问题，推荐采用临时文件名+原子重命名的方案，从根本上规避半文件被抓取的风险：

• Unix侧Java写入文件时，先将内容写入到带特殊后缀的临时文件（例如.tmp、.part），文件写入完成、关闭文件流后，再执行重命名操作，去掉临时后缀生成正式文件名
• 同挂载点下的重命名操作在NFS协议中是原子操作，Windows侧只会看到「临时文件存在」或「正式文件存在」两种状态，不存在中间过渡的半写入状态
• PowerShell侧调整检查逻辑，仅处理不带临时后缀的正式文件即可，只要正式文件出现，就说明Unix侧已经完成全量写入，不会出现损坏的情况

如果Java程序改造难度大，也可以在Unix侧增加本地中转逻辑：先将S3文件写入Unix本地磁盘，写入完成后再mv到NFS共享目录，效果和上述方案完全一致。

临时优化方案（无需修改写入侧） #

如果暂时无法调整Unix侧逻辑，可以优化PowerShell的判断规则，在最后写入时间的基础上增加文件大小稳定性校验，比单纯的固定等待可靠性高很多，参考代码如下：

# 仅移动大小稳定且最后写入时间超过30秒的文件
$targetFiles = Get-ChildItem -Path "NFS共享目录路径" -File
foreach ($file in $targetFiles) {
    $preSize = $file.Length
    Start-Sleep -Milliseconds 2000
    $curSize = (Get-Item -Path $file.FullName).Length
    # 两次检查大小一致且最后写入时间早于30秒前
    if ($preSize -eq $curSize -and $file.LastWriteTime -lt (Get-Date).AddSeconds(-30)) {
        Move-Item -Path $file.FullName -Destination "目标处理目录路径"
    }
}

内容的提问来源于stack exchange，提问作者Gunther Schadow