C# 带锁的QueueUserWorkItem是否正确实现？

我实现了一种日志记录方法，如下所示：

 ThreadPool.QueueUserWorkItem((state) => {
    lock (appendLock) {
       using (StreamWriter log = File.AppendText(_logFile)) {
          log.WriteLine(message);
       }
    }
 }, null);

1:

锁是否必要？我想遍历日志记录，发现锁已经就位。因此，我没有修改代码，而是简单地封装到一个worker委托中

2：假设需要锁：这是将包含锁的代理排队的正确实现吗？多线程请求日志写入的可能性相当高。通过将委托排入工作线程队列，文件I/O执行的长度不应影响应用程序本身

3：假设几个
logWriteDelegate
工作人员已排队：是否会按照接收委托的顺序调用委托？i、 例如，现在上菜#32…现在上菜#331：是的，需要锁。它可以被多个线程访问，特别是因为您正在使用池

他说：好吧，会有用的。但它会将文件锁定，使其难以读取。有一些已经存在的日志框架已经在这个问题上做了很多工作——也许值得我使用其中的一个

3：没有；对于锁和池，这是不希望在最终文件中进行严格排序的两个独立原因。事实上，由于池的原因，单个线程的消息可能会出现无序。如果您想要排序，您需要写入（同步的）队列，并有一个专用的工作程序将数据（同步的）从队列中拉回来并写入日志文件。同样，现有的日志框架已经为您解决了这个问题。
不幸的是，由于许可、开源和其他法律障碍，现有的日志框架是不可能的。这意味着我需要提供一个线程安全的日志机制。保持文件锁定是可以的…日志通常不会被任何用户读取（除非我误解了什么）。感谢您提供的信息：我重新添加了一个队列，该队列将日志
操作
，该日志由
任务
对象监控。由于
队列
没有同步对象，因此在
锁定队列
对象上同步排队和退队。