100行代码就支持了多线程并发，批量写入日志
一，您选择用什么样的日志组件
日志组件，不得不提大名鼎鼎的Log4Net。比较常用的还有 Enterprise Library Logging，ServiceStack Logging。当然您还可以补充，我就只用过这几款。
上边提到的3款日志组件，都要在.config里加代码，特别是Log4Net，还要把SQL写在配置里。我就是仅仅只写个日志，还要配置这么多信息，让人略有不爽。
所以在很长一段时间里，我用下边这个方法写日志：
这个方法足够的简单，核心代码就只有那么5，6行，还包含容错机制。我就喜欢用这种简单的代码来处理简单的事。
二，多线程下引爆了问题
在多线程的情况下，比如100个线程同时需要写日志，上边提到的这个方法就力不从新了。
一个线程访问日志资源，另一个线程再去访问的时候，就会出现异常。
方法一：
public static Object _processLock = new Object();
private void Button_Click_1(object sender, RoutedEventArgs e)
{
lock (_processLock)
{
}
}
方法二：
public static Object _processLock = new Object();
private void Button_Click_1(object sender, RoutedEventArgs e)
{
Monitor.Enter(_processLock);
Monitor.Exit(_processLock);
}
这样，你不得不承认，我已经解决了多线程的问题。
但是有瓶颈，这些需要写日志的线程，必须要等前一个释放了锁资源，后一个线程才能访问的情况。
三，重新设计日志组件
先看图，再说一下我的思路：
1，不管有多少线程同时需要写日志，我都用一个临时队列来存放这些日志信息。
2，再启用一个Task任务把队列的日志批量存放到.log文件里。
3，附加一个小功能，每个日志存储的大小限制，当日志太大了，查看打开的时候比较慢。
四，具体的代码实现
1，在多线程的情况下，我们首先把日志压到Queue队列里
static ConcurrentQueue<Tuple<string, string>> logQueue = new ConcurrentQueue<Tuple<string, string>>();
在这儿，我为什么选用 ConcurrentQueue 而不是 Queue 。因为ConcurrentQueue 表示线程安全的先进先出 (FIFO) 集合。
当然你一定要用Queue也是可以的，但是要自己去实现锁机制，何必自找麻烦呢？
2，把日志队列里的数据，批量持久化到.log文件里
这个问题，让我很头大。我最开始的方法是：
持久化日志方法一：
a，申明一个Task任务，当我Task任务没有实现化时，先实例化，然后再进行持久化日志写入。
b，当我的Task任务，已经实例化了，并且是处于 IsCompleted 状态，我重新实例化Task，再进行持久化日志的写入。
static Task writeTask = default(Task);
异常信息：
理论是那么的美好，但是现实是那么残酷，当我跑单元测试的时候，一段时间后总是抛出如下错误。如果是有那位朋友知道其原因，把这个问题解决就完美了。
但是我不能因为这一个异常，导致我这个组件写不下去吧！活人不能被一泡尿给憋死。
追加：完整代码如下：
持久化日志方法二：
我采用了另外一种方法，在Task任务里我用信号量的方式来解决了些问题，完整代码如下：
static AutoResetEvent pause = new AutoResetEvent(false);
信号量法：
持久化日志方法三：
如果你感觉写一个日志类还用什么信号量这些技术，太复杂了，那也可以用最简单的方式，定时器来解决。
有同学一听定时器，就默默的笑了，但是这儿的坑也很深，首先了解一下这几个定时器的使用场合，再用不迟！
System.Windows.Threading.DispatcherTimer
System.Windows.Forms.Timer
System.Timers.Timer
System.Threading.Timer
定时器法：
五，结语
重新设计的日志组件，思路还是非常清晰的。只是在持久化日志时遇上了问题了。
持久化日志方法一，其实是很完美的解决方法，但是在高并发的时候，总是抛出异常，找不出原因。
持久化日志方法二，是我目前采用的方法，能够有效的解决问题。
持久化日志方法三，采用定时器解决，也是可行的。只是代码看起来很别扭。
欢迎大家热烈讨论，看有没有更好的解决方案。
阿里云客户端的实现(支持文件分块,断点续传,进度,速度,倒计时显示)