多请求并发保存web.config时报“进程无法访问文件，正被另一进程占用”错误

• 你当前的代码没有做任何并发控制，多请求同时触发时，多个线程会同时调用Configuration.Save()写web.config文件。文件系统的写入本身是排他锁机制，同一时间只允许一个进程/线程操作文件，其他线程抢不到锁就会抛出你遇到的占用错误。
• 额外补充：web.config是ASP.NET应用的核心配置文件，每次修改默认都会触发应用池回收，会直接导致当前所有会话丢失、缓存清空、请求阻塞，你这个每次请求就改web.config的设计本身就不符合常规开发规范。

1. 加互斥锁解决冲突（仅适合极低频率修改场景） #

如果你的配置修改频率非常低（比如每天不到10次），可以直接加锁保证同一时间只有一个线程操作配置文件，示例实现：

// 定义全局静态锁对象
private static readonly object _configWriteLock = new object();

// 配置修改逻辑
lock (_configWriteLock)
{
    Configuration config = ConfigurationManager.OpenExeConfiguration(string.Empty);
    ConfigurationSection section = config.GetSection(_appSettings);
    // 此处写你修改配置节的逻辑
    config.Save(ConfigurationSaveMode.Modified);
    // 强制刷新内存中的配置，避免后续读取到旧值
    ConfigurationManager.RefreshSection(_appSettings);
}

这个方案只能解决文件占用报错，还是会触发应用池回收，不适合高频修改场景。

2. 替换动态配置的存储方案（最推荐） #

彻底放弃修改web.config的设计，把需要频繁更新的动态配置转移到其他存储：

• 自定义JSON/XML配置文件：自己读写自定义配置文件，加锁操作就不会触发应用重启
• 关系型数据库：把动态配置存在表里，读写性能足够支撑普通并发量
• 分布式缓存：如果是分布式部署的服务，用Redis这类缓存存动态配置最合适
  这个方案从根本上解决了web.config修改的所有问题，性能和稳定性都符合生产环境要求。

3. 临时兼容方案（不推荐，仅应急用） #

如果暂时改不了核心逻辑，可以给Save方法加强制覆写参数，忽略冲突直接写入：

config.Save(ConfigurationSaveMode.Modified, true);

这个方案有概率丢修改，只能临时用，不建议长期留着。

内容的提问来源于stack exchange，提问作者Sagar Jena