File.setReadOnly()本质是设置文件系统只读属性，非强制锁机制；它仅通过移除写权限限制Java程序写入，但无法阻止有权限的用户或进程修改、删除或绕过该限制。
File.setReadOnly() 并不能真正“锁定”文件，它只是将文件设置为只读属性（即移除写权限），属于操作系统层面的轻量级防护，**无法阻止有权限的进程或用户修改文件**。在 Java 中调用该方法后，其他程序（包括你的 Java 应用自身）若尝试写入该文件，会抛出 IOException（如 AccessDeniedException），但这依赖于底层文件系统和运行时权限，并非强制锁机制。
它实际起什么作用？
该方法本质是调用操作系统的文件属性设置（如 Linux 的 chmod -w，Windows 的只读属性标记）。效果取决于：
- 当前进程是否有权修改文件权限（例如 Linux 下非文件所有者可能无权改 chmod）；
- 目标文件系统是否支持该属性（如某些网络文件系统或 FAT32 不完全支持）；
- 运行 Java 的用户是否拥有绕过只读限制的能力（如 root / Administrator 可直接清除只读位并写入）。
为什么不能靠它防“运行时被修改”？
常见误解是认为 setReadOnly() 能像数据库行锁或文件通道锁一样阻塞写入。实际上：
- 它不阻塞任何进程 —— 其他程序仍可打开、删除、重命名、覆盖该文件（只要 OS 权限允许）；
- Java 自己再次调用
setWritable(true)就能轻易解除只读状态； - 用户手动右键取消“只读”勾选，或执行
chmod +w config.properties即可恢复可写。
更实用的防护建议
若目标是防止配置在运行期间被意外或恶意篡改，应组合使用以下策略：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
-
启动时加载进内存，后续全程只读访问：解析配置到不可变对象（如
Map.copyOf()、自定义Config类且字段final），关闭对原始文件的引用，避免反复读取； - 校验完整性（推荐）：启动时计算配置文件的 SHA-256 哈希并缓存；定时或关键操作前重新计算比对，发现不一致则告警或拒绝继续运行；
-
运行时加文件通道共享锁（有限效用）：用
FileChannel.lock(0, Long.MAX_VALUE, true)获取共享读锁（注意：Windows 上对同一文件多个读锁可行，但 Linux 多数文件系统不强制执行读锁，且锁在 JVM 退出或 channel 关闭后自动释放）； -
部署层控制：将配置文件放在仅应用用户可读、其他用户无写权限的目录中（如
/etc/myapp/配置属主myapp:myapp，权限644），配合最小权限原则运行 Java 进程。
示例：加载后禁止再写 + 简单哈希校验
```java
Path configPath = Paths.get("conf/app.conf");
// 启动时读取并计算哈希
byte[] raw = Files.readAllBytes(configPath);
String initialHash = DigestUtils.sha256Hex(raw); // Apache Commons Codec
Config loadedConfig = parseConfig(new ByteArrayInputStream(raw));
// 后续只操作 loadedConfig，不再碰文件
// 必要时校验：
if (!initialHash.equals(DigestUtils.sha256Hex(Files.readAllBytes(configPath)))) {
throw new IllegalStateException("Config file was modified!");
}
```
不复杂但容易忽略：真正的防护不在单个 API，而在加载策略、权限设计与运行时检查的组合。
