我有一个可供多个用户同时访问的应用程序，并且利用了使用OAuth 2.0的API。该应用程序依赖一个文件来存储信息，例如用于进行API调用的访问令牌。当访问令牌过期时，应用必须经历通过API获取新令牌的过程，并将其保存到文件中。如果有多个人尝试一次执行此操作，那么这些令牌中只有一个会起作用。
建议的解决方案是，当用户开始获取新令牌的过程时，仅通过读取访问权限将FileStream打开到特定文件。然后，该FileStream将在处理结束时被丢弃。该应用程序将检查该文件是否可以写入。如果不能，则意味着其他人正在获取新令牌，并且该应用程序实例必须等待，直到获得新令牌为止。
如果应用程序在该过程中崩溃，那么对该文件的锁定会如何处理？我以为操作系统会释放该锁，但是如果崩溃是由于非托管代码中的某些原因或不是未处理的异常的其他原因导致的，那该怎么办？
答案 0 :(得分：0)
好吧，当您打开文件时，它具有这些模式。每当您打开文件时，都会创建一个处理程序并将其传递给您，然后将其分配给引用
未共享的打开文件只有在被调用方应用关闭且具有独占访问权限后，才能在同一调用方应用程序或其他调用方应用程序中打开。
如果以共享模式打开文件，则系统会将请求的访问和共享模式与文件打开时指定的访问和共享模式进行比较。如果您指定的访问或共享模式与上一个调用中指定的模式冲突，则打开文件失败。
我们的应用程序遇到严重崩溃，您的托管代码资源将不会被应用程序清除，也不会尝试恢复它们。基本上，代码中的所有GC内容都不会运行。但是，操作系统在您执行之后仍会尝试清除。这样可以解决内存，句柄和其他系统对象未释放的问题，您的FileStream处理程序也可以解决
我的最佳猜测是，如果文件处于共享模式，则应用崩溃后，操作系统清理将释放该文件上的锁定。请确保您的应用程序的逻辑永远不会再达到该状态。
对于非托管代码段也是如此，因为它直接调用Managed OS api，并且OS处理程序将创建，并且如果os处理程序在崩溃时，这些处理程序将由OS自行处理。
这是Windows 10防止内存位置在其系统文件位置上被劫持的方式。
答案 1 :(得分：-1)
如果您使用的是任何非托管代码，那么中间就会出现异常。系统将保留该文件的使用状态。这就是为什么在我们的代码中始终使用“ using”块或尝试{} catch {}并最终{}。 一旦对象超出范围，
using语句将确保您自己释放资源，而您需要在try，catch和finally块中显式释放它们。