博客园_轨迹2003

Linux虚拟内存

2011-09-18T02:05:00Z

当你运行一个程序，程序中有许多东西需要存储，堆、栈以及各种功能库。而这一切在你写程序时可能都不需要自己控制，Linux内核会帮你完成这些存储的调度，你只需要告诉它你需要做什么，内核就会在合适的地方给你分配内存空间。本文主要通过几个实例程序的内存使用研究，来为大家展示Linux的内存使用状况。

第一个例子：下面一段程序会打印出程序的pid（进程号）后挂起。

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>

int main() {
  printf("run `pmap %d`\n", getpid());
  pause();
}

将上面代码保存成文件 mem_munch.c 然后运行下面程序编译并执行：

$ gcc mem_munch.c -o mem_munch
$ ./mem_munch
run `pmap 25681`

上面进程号是25681，可能你试验的结果会不太一样。

下面我们通过pmap命令来查看一下这个小程序的内存使用情况

$ pmap 25681
25681:   ./mem_munch
0000000000400000      4K r-x--  /home/user/mem_munch
0000000000600000      4K r----  /home/user/mem_munch
0000000000601000      4K rw---  /home/user/mem_munch
00007fcf5af88000   1576K r-x--  /lib/x86_64-linux-gnu/libc-2.13.so
00007fcf5b112000   2044K -----  /lib/x86_64-linux-gnu/libc-2.13.so
00007fcf5b311000     16K r----  /lib/x86_64-linux-gnu/libc-2.13.so
00007fcf5b315000      4K rw---  /lib/x86_64-linux-gnu/libc-2.13.so
00007fcf5b316000     24K rw---    [ anon ]
00007fcf5b31c000    132K r-x--  /lib/x86_64-linux-gnu/ld-2.13.so
00007fcf5b512000     12K rw---    [ anon ]
00007fcf5b539000     12K rw---    [ anon ]
00007fcf5b53c000      4K r----  /lib/x86_64-linux-gnu/ld-2.13.so
00007fcf5b53d000      8K rw---  /lib/x86_64-linux-gnu/ld-2.13.so
00007fff7efd8000    132K rw---    [ stack ]
00007fff7efff000      4K r-x--    [ anon ]
ffffffffff600000      4K r-x--    [ anon ]
 total             3984K

上面的结果是这个程序的内存使用情况，其实更确切的说是这个程序认为它使用内存的情况。从上面的结果我们能看到，当你访问libc库时，实际上是对内存地址00007fcf5af88000的访问，当你访问ld库时，实际上是对内存地址00007fcf5b31c000的访问。

上面的输出可能还比较抽象，下面我们修改一下上面的程序，我们在程序的堆和栈上各放一块数据。

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <stdlib.h>

int main() {
  int on_stack, *on_heap;

  //局部变量是放在栈上的，所以 on_stack 的地址就是栈的初始地址
  on_stack = 42;
  printf("stack address: %p\n", &on_stack);

  //malloc 的内存是在堆上分配的
  on_heap = (int*)malloc(sizeof(int));
  printf("heap address: %p\n", on_heap);

  printf("run `pmap %d`\n", getpid());
  pause();
}

编译运行：

$ ./mem_munch
stack address: 0x7fff497670bc
heap address: 0x1b84010
run `pmap 11972`

然后再用pmap命令查看一下内存使用：

$ pmap 11972
11972:   ./mem_munch
0000000000400000      4K r-x--  /home/user/mem_munch
0000000000600000      4K r----  /home/user/mem_munch
0000000000601000      4K rw---  /home/user/mem_munch
0000000001b84000    132K rw---    [ anon ]
00007f3ec4d98000   1576K r-x--  /lib/x86_64-linux-gnu/libc-2.13.so
00007f3ec4f22000   2044K -----  /lib/x86_64-linux-gnu/libc-2.13.so
00007f3ec5121000     16K r----  /lib/x86_64-linux-gnu/libc-2.13.so
00007f3ec5125000      4K rw---  /lib/x86_64-linux-gnu/libc-2.13.so
00007f3ec5126000     24K rw---    [ anon ]
00007f3ec512c000    132K r-x--  /lib/x86_64-linux-gnu/ld-2.13.so
00007f3ec5322000     12K rw---    [ anon ]
00007f3ec5349000     12K rw---    [ anon ]
00007f3ec534c000      4K r----  /lib/x86_64-linux-gnu/ld-2.13.so
00007f3ec534d000      8K rw---  /lib/x86_64-linux-gnu/ld-2.13.so
00007fff49747000    132K rw---    [ stack ]
00007fff497bb000      4K r-x--    [ anon ]
ffffffffff600000      4K r-x--    [ anon ]
 total             4116K

这次多出了上面红色的一行内容，红色内容就是堆的起始位置：

0000000001b84000    132K rw---    [ anon ]

在我们程序运行的输出里也有一行红色的输出，这是这个地址在程序中的内存地址：

heap address: 0x1b84010

这两个地址基本上是一样的，其中的anon是Anonymous的缩写，表明这段内存是没有文件映射的。

我们再看上面绿色的两行，与上面相对应，这两行分别是用pmap 和应用程序看到的栈起始地址：

00007fff49747000    132K rw---    [ stack ]

stack address: 0x7fff497670bc

上面说到的内存使用，都只是程序认为自己对内存的使用，实际上程序在分配内存是不知道系统内存的状态的。所以上面的输出都只是从程序自己的角度看到的内存使用状况。比如在上面的例子中，我们看到程序的内存地址空间是从0×0000000000400000到0xffffffffff600000的所有地址（而0xffffffffff600000到0×00007fffffffffffffff之间的地址是有特殊用处的，这里不多讲）。这样算下来，我们总共可以使用的内存空间有1千万TB。

但是实际上目前没有硬件能有1千万TB的物理内存。为什么操作系统会如此设计呢？原因有很多，可以看这里，但也正因此，我们可以使用远远超出物理内存大小的内存空间。

内存映射

内存映射的原理就是让操作系统将一个文件映射到一段内存中，然后在操作这个文件内存就可以像操作内存一样。比如我们创建一个完全内容随机的文件，然后将它用内存映射的方式映射到一段内存空间中。那么我们在这段内存中随便取一位就相当于取到了一个随机数。下面就让我们来做这个实验，先用下面命令生成一个内容随机的文件。

$ dd if=/dev/urandom bs=1024 count=1000000 of=/home/user/random
1000000+0 records in
1000000+0 records out
1024000000 bytes (1.0 GB) copied, 123.293 s, 8.3 MB/s
$ ls -lh random
-rw-r--r-- 1 user user 977M 2011-08-29 16:46 random

然后我们用下面程序来将这个文件内容映射到内存，再从中取出随机数

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <stdlib.h>
#include <sys/mman.h>

int main() {
  char *random_bytes;
  FILE *f;
  int offset = 0;

  // open "random" for reading
  f = fopen("/home/user/random", "r");
  if (!f) {
    perror("couldn't open file");
    return -1;
  }

  // we want to inspect memory before mapping the file
  printf("run `pmap %d`, then press ", getpid());
  getchar();

  random_bytes = mmap(0, 1000000000, PROT_READ, MAP_SHARED, fileno(f), 0);

  if (random_bytes == MAP_FAILED) {
    perror("error mapping the file");
    return -1;
  }

  while (1) {
    printf("random number: %d (press  for next number)", *(int*)(random_bytes+offset));
    getchar();

    offset += 4;
  }
}

然后运行这个程序：

$ ./mem_munch
run `pmap 12727`, then press

下面我们通过一次次的按下回车键来从这个文件中读取随机数，按下几次后我们可以再通过pmap来查看其内存空间的情况：

$ pmap 12727
12727:   ./mem_munch
0000000000400000      4K r-x--  /home/user/mem_munch
0000000000600000      4K r----  /home/user/mem_munch
0000000000601000      4K rw---  /home/user/mem_munch
000000000147d000    132K rw---    [ anon ]
00007fe261c6f000 976564K r--s-  /home/user/random
00007fe29d61c000   1576K r-x--  /lib/x86_64-linux-gnu/libc-2.13.so
00007fe29d7a6000   2044K -----  /lib/x86_64-linux-gnu/libc-2.13.so
00007fe29d9a5000     16K r----  /lib/x86_64-linux-gnu/libc-2.13.so
00007fe29d9a9000      4K rw---  /lib/x86_64-linux-gnu/libc-2.13.so
00007fe29d9aa000     24K rw---    [ anon ]
00007fe29d9b0000    132K r-x--  /lib/x86_64-linux-gnu/ld-2.13.so
00007fe29dba6000     12K rw---    [ anon ]
00007fe29dbcc000     16K rw---    [ anon ]
00007fe29dbd0000      4K r----  /lib/x86_64-linux-gnu/ld-2.13.so
00007fe29dbd1000      8K rw---  /lib/x86_64-linux-gnu/ld-2.13.so
00007ffff29b2000    132K rw---    [ stack ]
00007ffff29de000      4K r-x--    [ anon ]
ffffffffff600000      4K r-x--    [ anon ]
 total           980684K

上面的输出和之前的大同小异，但是多出了上面红色的一行。这是我们上面的随机文件映射到内存中的内存。我们再使用pmap -x 选项来查看一下程序的内存使用，会得到下面的内容，其中RSS（resident set size）列表示真实占用的内存。

pmap -x 12727
12727:   ./mem_munch
Address           Kbytes     RSS   Dirty Mode   Mapping
0000000000400000       0       4       0 r-x--  mem_munch
0000000000600000       0       4       4 r----  mem_munch
0000000000601000       0       4       4 rw---  mem_munch
000000000147d000       0       4       4 rw---    [ anon ]
00007fe261c6f000       0       4       0 r--s-  random
00007fe29d61c000       0     288       0 r-x--  libc-2.13.so
00007fe29d7a6000       0       0       0 -----  libc-2.13.so
00007fe29d9a5000       0      16      16 r----  libc-2.13.so
00007fe29d9a9000       0       4       4 rw---  libc-2.13.so
00007fe29d9aa000       0      16      16 rw---    [ anon ]
00007fe29d9b0000       0     108       0 r-x--  ld-2.13.so
00007fe29dba6000       0      12      12 rw---    [ anon ]
00007fe29dbcc000       0      16      16 rw---    [ anon ]
00007fe29dbd0000       0       4       4 r----  ld-2.13.so
00007fe29dbd1000       0       8       8 rw---  ld-2.13.so
00007ffff29b2000       0      12      12 rw---    [ stack ]
00007ffff29de000       0       4       0 r-x--    [ anon ]
ffffffffff600000       0       0       0 r-x--    [ anon ]
----------------  ------  ------  ------
total kB          980684     508     100

如果你的虚拟内存占用（上面的Kbytes列）都是0，不用担心，这是一个在Debian/Ubuntu系统上pmap -x命令的bug。最后一行输出的总占用量是正确的。

现在你可以看一下RSS那一列，这就是实际内存占用。在random文件上，你的程序实际上可以访问在00007fe261c6f000之前的数十亿字节的内存地址，但是只要你访问的地址超过4KB，那么操作系统就会去磁盘上查找内容。也就是说实际上只有4KB的物理内存被使用了。只有访问这4KB的东西时，才是真正的内存操作。其它部分虽然你使用的也是内存操作函数来访问它，但是由于它没有被加载到内存中，所以在这些内容被访问的时候，操作系统会先去磁盘读random中读取内容到内存中。

如果我们把程序再修改一下，修改成下面这样，让程序把整个random文件都访问一遍。

#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <stdlib.h>
#include <sys/mman.h>

int main() {
  char *random_bytes;
  FILE *f;
  int offset = 0;

  // open "random" for reading
  f = fopen("/home/user/random", "r");
  if (!f) {
    perror("couldn't open file");
    return -1;
  }

  random_bytes = mmap(0, 1000000000, PROT_READ, MAP_SHARED, fileno(f), 0);

  if (random_bytes == MAP_FAILED) {
    printf("error mapping the file\n");
    return -1;
  }

  for (offset = 0; offset < 1000000000; offset += 4) {
    int i = *(int*)(random_bytes+offset);

    // to show we're making progress
    if (offset % 1000000 == 0) {
      printf(".");
    }
  }

  // at the end, wait for signal so we can check mem
  printf("\ndone, run `pmap -x %d`\n", getpid());
  pause();
}

现在我们的pmap -x命令就会得到如下输出：

$ pmap -x 5378
5378:   ./mem_munch
Address           Kbytes     RSS   Dirty Mode   Mapping
0000000000400000       0       4       4 r-x--  mem_munch
0000000000600000       0       4       4 r----  mem_munch
0000000000601000       0       4       4 rw---  mem_munch
0000000002271000       0       4       4 rw---    [ anon ]
00007fc2aa333000       0  976564       0 r--s-  random
00007fc2e5ce0000       0     292       0 r-x--  libc-2.13.so
00007fc2e5e6a000       0       0       0 -----  libc-2.13.so
00007fc2e6069000       0      16      16 r----  libc-2.13.so
00007fc2e606d000       0       4       4 rw---  libc-2.13.so
00007fc2e606e000       0      16      16 rw---    [ anon ]
00007fc2e6074000       0     108       0 r-x--  ld-2.13.so
00007fc2e626a000       0      12      12 rw---    [ anon ]
00007fc2e6290000       0      16      16 rw---    [ anon ]
00007fc2e6294000       0       4       4 r----  ld-2.13.so
00007fc2e6295000       0       8       8 rw---  ld-2.13.so
00007fff037e6000       0      12      12 rw---    [ stack ]
00007fff039c9000       0       4       0 r-x--    [ anon ]
ffffffffff600000       0       0       0 r-x--    [ anon ]
----------------  ------  ------  ------
total kB          980684  977072     104

我们可以看到，random文件映射实际占用内存量已经和random文件大小一致了，也就是也random文件通过循环访问，其内容已经完全加载到内存中了。现在我们再访问random文件的任何部分，实际上都是内存操作。而不会穿透到磁盘。

本文链接

WINDOWS进程或线程号为什么是4的倍数

2011-09-18T01:53:00Z

今天看到一篇文章作者问为什么System进程号是4.记得之前在《windows内核原理与实现》里面看过，但是就是想不起来了。搜集了一些资料解释了原因。

原来进程Id和线程Id都是基于全局的句柄表PspCidTable生成，也就是句柄表的索引号。句柄表除了作为对象引用的容器以外，还有另一个用法：作为分配进程和线程的唯一ID 的有效手段。进程有一个唯一ID，称为UniqueProcessId；线程有一个CLIENT_ID 成员Cid，其中包含了所属进程的唯一ID 和线程自身的唯一ID。这些唯一ID 是怎么生成的呢？它们是通过调用ExCreateHandle 函数，在一个全局的句柄表PspCidTable 中创建的句柄索引值。此句柄表也称为CID 句柄表（Client ID handle table），它没有被加入到系统的句柄表链表中。CID 句柄表中的每个句柄表项都包含了进程或线程的对象地址。

因此，进程和线程的唯一ID 值都是4 的倍数，其中4 是第一个句柄索引值，它被分配给System 进程的唯一ID（因为System 进程是第一个通过PspCreateProcess 函数创建的进程）。0 是专门保留给空闲进程的，它并非通过ExCreateHandle 函数而获得。CID 句柄表严格按照FIFO 来重用句柄表项，所以，一个句柄表项被释放以后，要等到其他的空闲句柄表项都被重用一遍以后才会被再次使用。由于CID 句柄表项保存了进程或线程的对象地址，所以，在内核中，根据进程或线程的唯一ID 值，总是可以很方便地找到相应的对象地址，函数PsLookupProcessThreadByCid、PsLookupProcessByProcessId 和PsLookup-ThreadByThreadId 正是利用了CID 句柄表的这一能力，参见base\ntos\ps\pscid.c 文件中的代码。

PspCidTable的说明如下：

PspCidTable也是一个句柄表,其格式与普通的句柄表是完全一样的.但它与每个进程私有的句柄表有以下不同:
1.PspCidTable中存放的对象是系统中所有的进线程对象,其索引就是PID和TID
2.PspCidTable中存放的直接是对象体(EPROCESS和ETHREAD),而每个进程私有的句柄表则存放的是对象头(OBJECT_HEADER)
3.PspCidTable是一个独立的句柄表,而每个进程私有的句柄表以一个双链连接起来。

至于为什么句柄表的号都是4的倍数呢？

一个进程的句柄表包含了所有已被该进程打开的那些对象的指针。对象句柄是用来检索句柄表的一个“伪索引”。对于句柄表机制，achillis <<Windows句柄表>>系列文章已经分析得很透彻了，只是对“句柄以4为步进”来源不明。经查，根源如下：

typedef struct _EXHANDLE
{
union
{
  struct
  {
   ULONG TagBits:2;
   ULONG Index:30;
  }
  HANDLE GenericHandleOverlay;
  #define HANLE_VALUE_INC 4
  ULONG_PTR Value;
}

}EXHANDLE,*PEXHANDLE;
此结构正是用来定义句柄类型。低2位TagBits为标志位Windows用于其它用途，故句柄值低2位对其作为句柄表索引本身无意义，所以等于4的倍数。有了以上分析，自然，在用句柄值为索引取句柄表项时，句柄值必须/4。因此程序中用到的句柄值并不能直接用来索引句柄表，也就有了“伪索引”说法。

本文链接

【知识总结】关于内存管理

2011-05-30T15:12:00Z

1.VM管理
　　一般操作系统的用的都是基于VM的内存管理，这样可以扩展有效的物理内存，热点数据在物理内存中，非热点数据会进去页面文件后等后备存储中，需要时中断取出，对于系统或应用来说这一机制是透明的。
目前有些性能较好的缓存应用也在使用VM进行内存管理，例如redis，真正没有测试过，据说性能提升明显，从理论上说，缓存的热点数据和非热点数据应该分别对待，这种机制还是可取的。
2.内存池
　　这里所说的内存池就是指一些应用上程序上的内存池，例如c语言开发的程序一般会有专门的内存池来管理内存，例如nignx的内存池。内存池存在的意义主要在于减少频繁的分配和释放内存(一般是操作系统的VM内存管理中保留和归还操作)，这一部分相对于IO来说消耗比较少，但是对于内存的频繁使用消耗就会比较明显。还有就是可以减少内存泄漏和内存碎片的产生。
3.GC管理
　　一些很高级的语言提供了GC管理的机制，例如C#或Java等，其实GC本身就是一个大的内存池，托管堆就是GC管理的对象，只不过这个内存池来说比较高级而已，算法比较适合于业务语言的需求。其实C#使用特殊的函数完全可以从非托管堆上分配内存，也可以实现一个高性能的内存池，这样GC的压力就会降下来，当然这都是对于大量而且频繁的内存使用而言，否则完全没有必要。
4.对象池
　　对于一些使用C#或Java开发的应用来说，如果面临着同一种类型的大量对象的new操作，而且马上使用完了，GC可能就可以回收的情形来说，可以尝试使用一下对象池(连接池，线程池也可以算)。对象池一般是给一个初始的容量参数，一次性或多次创建很多对象，每次需要创建时取一个即可使用，使用完了主动归还，如果不归还可能也会内存泄漏，因为对象池还在引用它（如果算法写好了应该可以收回）,对象池对于以上频繁的创建生命周期很短的对象来说很有效，可以明显降低GC的压力，留出更多的CPU时间给业务使用。

5.总结

　　频繁的内存申请，释放，拷贝应该得到优化!

本文链接

【知识分享】异步调用与多线程的区别

2010-12-24T08:45:00Z

随着拥有多个硬线程CPU（超线程、双核）的普及，多线程和异步操作等并发程序设计方法也受到了更多的关注和讨论。本文主要是想探讨一下如何使用并发来最大化程序的性能。

多线程和异步操作的异同

多线程和异步操作两者都可以达到避免调用线程阻塞的目的，从而提高软件的可响应性。甚至有些时候我们就认为多线程和异步操作是等同的概念。但是，多线程和异步操作还是有一些区别的。而这些区别造成了使用多线程和异步操作的时机的区别。多线程是实现异步的一个重要手段，但不是唯一手段，对以一个单线程程序也可以是异步执行的。

异步操作的本质

所有的程序最终都会由计算机硬件来执行，所以为了更好的理解异步操作的本质，我们有必要了解一下它的硬件基础。熟悉电脑硬件的朋友肯定对DMA这个词不陌生，硬盘、光驱的技术规格中都有明确DMA的模式指标，其实网卡、声卡、显卡也是有DMA功能的。DMA就是直接内存访问的意思，也就是说，拥有DMA功能的硬件在和内存进行数据交换的时候可以不消耗CPU资源。只要CPU在发起数据传输时发送一个指令，硬件就开始自己和内存交换数据，在传输完成之后硬件会触发一个中断来通知操作完成。这些无须消耗CPU时间的I/O操作正是异步操作的硬件基础。所以即使在DOS 这样的单进程（而且无线程概念）系统中也同样可以发起异步的DMA操作。异步编程的目的就是为了能够是实现并行，但不仅是提高多处理器间的并行度，同时也是提高处理器与I/O处理器的并行度。非阻塞模式一般特指异步的I/O 操作，可以算是异步编程的一种类型。

线程的本质

线程不是一个计算机硬件的功能，而是操作系统提供的一种逻辑功能，线程本质上是进程中一段并发运行的代码，所以线程需要操作系统投入CPU资源来运行和调度。

异步操作的优缺点

因为异步操作无须额外的线程负担，并且使用回调的方式进行处理，在设计良好的情况下，处理函数可以不必使用共享变量（即使无法完全不用，最起码可以减少共享变量的数量），减少了死锁的可能。当然异步操作也并非完美无暇。编写异步操作的复杂程度较高，程序主要使用回调方式进行处理，与普通人的思维方式有些初入，而且难以调试。

多线程的优缺点

多线程的优点很明显，线程中的处理程序依然是顺序执行，符合普通人的思维习惯，所以编程简单。但是多线程的缺点也同样明显，线程的使用（滥用）会给系统带来上下文切换的额外负担。并且线程间的共享变量可能造成死锁的出现。

适用范围

在了解了线程与异步操作各自的优缺点之后，我们可以来探讨一下线程和异步的合理用途。我认为：当需要执行I/O操作时，使用异步操作比使用线程+同步 I/O操作更合适。I/O操作不仅包括了直接的文件、网络的读写，还包括数据库操作、Web Service、HttpRequest以及.net Remoting等跨进程的调用。而线程的适用范围则是那种需要长时间CPU运算的场合，例如耗时较长的图形处理和算法执行。但是往往由于使用线程编程的简单和符合习惯，所以很多朋友往往会使用线程来执行耗时较长的I/O操作。这样在只有少数几个并发操作的时候还无伤大雅，如果需要处理大量的并发操作时就不合适了。

对于CPU来说以下意味着什么

线程：意味了CPU的一组寄存器

进程：意味着CPU的页目录寄存器

IO：意味着一些端口或内存地址空间中一些地址

本文链接

【知识分享】了解WINDOWS内核的关键组件和功能

2010-12-24T05:48:00Z

通过WRK可以了解到，WINDOWS内核绝大部分源代码是由C语言实现，只有部分与处理器相关的调度代码是通过汇编语言实现。最近半年我对WINDOWS平台本身有很高的兴趣，其实我作为应用程序开发人员对于WINDOWS内核没有必要知道的太多，但是了解下不仅对我应用程序排查问题有帮助，而且WINDOWS内核中有很多良好的设计也是我们应用开发人员值得学习的，例如说内存堆管理，IO体现等，甚至可以引用到自己的项目中。很多程序员和架构师每天围绕WINDOWS展开工作，因为我们的程序就是基于WINDOWS的，WINDOWS占领了PC的市场，关键是不得不用。我们开发的程序可以认为是WINDOWS能力的扩展，在WINDWOS平台下的主要扩展方式有以下几种：窗体应用程序，控制台应用程序，服务程序，驱动程序（可以认为是内核模块的扩展），本地程序。

1.扩展类型

窗体应用程序：这个大家最熟悉不过了，直接用MFC写一个窗体程序，用Winform写一个窗体程序。窗体程序一般都需要在某个用户的Session的桌面中运行，基于WINDOWS子系统，采用GDI做显示输出技术，基于WINDOWS的消息机制，有消息循环和窗体函数，所以窗体程序会有大量的GDI对象生成，窗体应用程序也是WINDOWS作为客户端系统最为普遍的应用。

控制台应用程序：控制台的程序是最早的DOS下16位应用在WINDOWS下的兼容方式（不过现在已经是32位为主了），有标准输入，标准输出和标准错误，一般是作为计算机管理人员使用。控制台程序与WINDWOS窗体应用的运行机制完全不同，窗体程序是基于GDI，内核级由win32k.sys处理，而控制台应用程序一般由csrss.exe（下文会有介绍）管理。

服务程序：这是WINDOWS作为服务器端应用时普遍采用的方式，具有守护特性（无需用户登录无需退出），类似与LINUX下的DAEMON进程，服务程序的运行不需要用户登录，一般由LOCAL SERVICE，NETWORK SERVICE，SYSTEM用户运行，所以没有用户界面，所以成为服务器端的主要应用方式是因为这种服务程序很多都是使用线程池来做IO处理，例如处理网络连接和数据库操作等。此前之前有人试图在WINDOWS服务中启动用户界面程序，虽然可能通过一些技巧会实现，但是这种不是服务程序设计的初衷，只能说明应用架构设计的不合理。

驱动程序：这里的驱动程序特指运行在WINDOWS内核模式下的扩展模块或设备驱动程序，WINDOWS内核通过IO管理器等执行体模块对驱动程序进行管理，可以是协议驱动程序，设备驱动程序，文件系统驱动程序等，一般基于一定的驱动程序开发模型由第三方提供。此外WINDOWS对于驱动程序的一个映像只允许加载一次，也就是说两个驱动程序不能使用同一个映像文件。

本地程序：这个可能大家最为陌生，本地程序不是我们常说的WIN32本地程序，WIN32本地程序是指基于WINDOWS子系统的本地代码程序。而这里的本地程序是WINDOWS的原生程序，一般直接基于ntdll.dll,而不是基于user32.dll，kernel32.dll等子系统dll。举个例子就是WINDOWS的第一个用户态进程smss.exe，完成会话管理任务和启动一些其他子系统进程。还有就是我们常用的瑞星杀毒软件在启动的时候会执行内核扫描，实际上这个程序就是本地程序。

所有以上程序都可以使用VS开发，只是改变一些配置选项，需要安装例如WINDOWS SDK和WINDOWS DDK等开发包。

其他一些扩展，例如WINDOWS的SHELL程序explorer.exe的扩展，IE浏览器的插件，还有就是登录认知的GINA扩展等。目前SHELL编程已经成为独立的开发方向。

2.内核模块

看一副经典的图片吧，这是一幅WINDOWS内核组件的原图，这里的内核是指大内核，而不是图中的kernel的微内核，微内核是特指线程调度模块。

在WINDOWS中可执行的代码在CPU上运行时会有用户模式和内核模式两种，CPU不是工作在内核模式就是工作在用户模式，一般用户模式在CPU的低权限级别运行，当线程运行在用户模式时只能访问进程空间的资源，对于32位系统只能使用2GB以下地址空间(最大3GB)，如果需要访问其他资源需要陷入内核模式。当线程工作在内核态时能够访问到4GB全地址空间，包括系统空间的映射。图中NTDLL正是将用户态和内核态隔开的模块，NTDLL通过特殊的CPU指令可以进入内核态，反之亦然。
用户态中包括应用程序，子系统，服务和一些系统管理进程，最后都是通过NTDLL进入内核态的。
内核态中包括SDT（服务分发表，系统线程），执行体（包括内存管理，进程线程管理，IO管理等），微内核（调度）。此外还包括第三方的驱动程序（其实很多也是MICROSOFT提供的），和WINDOWS的子系统内核模块win32k.sys。
内核态还有一个很重要的hal.dll，实现WINDOWS内核的跨平台（硬件平台）。

3.重要文件

Ntoskrnl.exe: 包含执行体和内核部分，是大内核的主要部分，完全运行在内核态，可以说是WINDOWS系统的核心部分。WRK的源代码就是这一部分。

Ntkrnlpa.exe (32位): Ntoskrnl的PAE版本。

Hal.dll：硬件抽象层，WINDOWS的跨平台特性很多就要从这个文件说起，一共大概4个版本，在WINDOWS系统安装时会根据硬件平台选择一个进行拷贝之后重命名。

Win32k.sys: WINDOWS子系统的内核部分，包括了消息，图形的内核部分等。窗口显示；鼠标、键盘输入接收；传递用户消息，GDI。

Ntdll.dll：用户态子系统DLL。

Kernel32.dll，Advapi32.dll，User32.dll，Gdi32.dll：一些用户态的WINDOWS子系统DLL，WINDOWS共支持三种子系统WINDOWS，POSIX，OS/2。将documented Windows API映射到undocumented的kernel-mode system service call。

Csrss.exe：Console管理，创建/销毁进程和线程，支持16位进程。

Ntdll.dll：User-mode应用调用到Windows executive system service的接口，Subsystem, native images的内部支持。

Idle process：一个CPU一个线程，用来计算CPU空闲时间，进程编号为0，一般由WINDOWS的初始化程序退化而成。无映像文件。

System process系统，进程编号为4，一些系统线程会被附加在此进程中，无映像文件。

Smss.exe：第一个user-mode进程。

Winlogon.exe：登录界面。可替换。GINA。

Services.exe and Svchost.exe：服务管理和宿主进程。

Lsass.exe：验证用户登录信息。

Userinit.exe: 初始化用户信息，执行shell程序（explorer.exe）。

4.重要部分

内存管理
同步和线程调度
IO系统
服务分发
进程通信
网络系统
文件系统
WINDOWS子系统

5.推荐资源

《WINDOWS核心编程》
《深入解析WINDOWS内核》
《WINDOWS内核原理与应用》
Sysinternals工具

谢谢收看，有问题一起讨论！

本文链接

【经验总结】C#常用线程同步方法应用场景和实现原理

2010-12-21T03:31:00Z

简单描述volatile，Interlocked，lock，Mutex，Semaphore，Spin lock，AutoResetEvent，ManualResetEvent，ReaderWriterLockSlim，MethodImplAttribute，WaitHandle常用同步机制的原理和使用场景。

volatile
只是C#的一个关键字，告诉编译器不能将声明的这个变量进行CPU内部缓存，只能在主内存中操作，类型有限制，volatile并不能实现真正的同步，因为它的操作级别只停留在变量级别，而不是原子级别。如果是在单处理器系统中，是没有任何问题的，变量在主存中没有机会被其他人修改，因为只有一个处理器，这就叫作processor Self-Consistency。但在多处理器系统中，可能就会有问题。每个处理器都有自己的data cache，而且被更新的数据也不一定会立即写回到主存。所以可能会造成不同步，但这种情况很难发生，因为cache的读写速度相当快，flush的频率也相当高，只有在压力测试的时候才有可能发生，而且几率非常非常小。本质上说并非绝对的同步方法。

Interlocked
对于例如int变量等的原子操作，效率高，可靠性高，一般通过CPU的专用指令实现的锁住内存总线实现的。

lock
lock与Monitor本身是一致的，lock是做到了C#的关键字一级，是.net对象自身支持的的一种同步机制，对象中有相关的结构支持这种轻量级的线程同步，实现机制类似于CRITICAL_SECTION，但是CRITICAL_SECTION具有跨进程特性，而lock只能实现同一进程中的线程同步，在C#开发中很常用。

Mutex
是WIN32下的突变体内核对象的封装，类似于一间屋子只能进入一个人。是它的一个.net封装，效率比较低，由于突变体是一种windows内核对象，需要开销很大，但是支持跨进程，通过给Mutex命名的方式支持进程间同步，甚至可以跨服务器访问，是一种服务器之间同步的选择。Mutex的拥有者才能释放这个Mutex，其他进程不能释放，可能是考虑到安全问题。Mutex是一种基于线程调度的同步方式，控制的是线程的调度，实现了sleep，如果有信号可以通知内核线程调度程序调度等待线程。

Semaphore(Binary semaphore)
基于WIN32的Semaphore，也是一种基于线程调度，基本很类似于Mutex，与Mutex不同之处在于Semaphore允许多人进入同一间屋子，使用count计数来实现，当允许数量为1时叫做Binary semaphore，这时候就是基本和Mutex很类似的，但是没有Mutex拥有者一说，可由任何进程进行资源释放。

Spin lock
这是一个内核态概念。spin lock与semaphore的主要区别是spin lock是busy waiting，而semaphore是sleep。对于可以sleep的进程来说，busy waiting当然没有意义，CPU只是在那里空转而已，而且IRQL比较高，适合于等待时间比较短的场景。对于单CPU的系统，busy waiting当然更没意义（没有CPU可以释放锁），所有Spin lock只对多CPU才有意义，因此，只有多CPU的内核态非进程空间，才会用到spin lock。其实也就是类似mutex的作用，串行化对 critical section的访问。但是mutex不能保护中断的打断，也不能在中断处理程序中被调用。而spin lock也一般没有必要用于可以sleep的进程空间。幸好它是内核级的，如果是用户级的会很危险。

AutoResetEvent，ManualResetEvent (Event)
这两种的实现都是基于WIN32的Event原理，同步事件有两种：AutoResetEvent 和 ManualResetEvent。它们之间唯一的不同在于，无论何时，只要 AutoResetEvent 激活线程，它的状态将自动从终止变为非终止。相反，ManualResetEvent 允许它的终止状态激活任意多个线程，只有当它的 Reset 方法被调用时才还原到非终止状态。

ReaderWriterLockSlim
这个也是lock的封装，对资源的访问方式有共享和独占方式，例如我们控制对某个资源读贡献或者写独占，那么这个类可以派上用场。

SynchronizationAttribute ，MethodImplAttribute
这两个属于类特性和方法的特性，标识某个类或方法是同步方法，本质上基于lock的实现。

WaitHandle
可以通过调用一种等待方法，如 WaitOne、WaitAny 或 WaitAll，让线程等待事件。System.Threading.WaitHandle.WaitOne 使线程一直等待，直到单个事件变为终止状态；System.Threading.WaitHandle.WaitAny 阻止线程，直到一个或多个指示的事件变为终止状态；System.Threading.WaitHandle.WaitAll 阻止线程，直到所有指示的事件都变为终止状态。当调用事件的 Set 方法时，事件将变为终止状态。WaitOne基于WaitSingleObject，WaitAny 或 WaitAll基于WaitmultipleObject，具体由后面参数来决定。WaitmultipleObject实现要比WaitSingleObject复杂的多，性能也不好，尽量少用。

本文链接

【代码分享】写一个RPC批量调用支持（支持串行和并行模式）

2010-08-26T05:45:00Z

我在做项目过程中遇到这方面的问题，于是自己封装了一个组件来解决RPC的批量调用问题（需要获取每个RPC的返回结果），批量中的量最好也别太大，否则不是等待时间很长就是耗费很多线程。

问题描述：对外需要提供一个异步RPC接口，但是对方要求是可以批量查询某些数据，内部也有类似的异步RPC接口，但是是单条查询。我这里需要做一个转换，需要将批量的拆分路由给单条的。而且类似这种需求的接口还挺多。所以为了代码简洁，控制上通用和规范些。

难点：
1.代码控制上，由于涉及很多异步回调+批量增加代码难度。
2.需要考虑各种异常和不hang住线程。
3.更好考虑到性能问题，批量的也许会对内部单条的接口造成压力。

本类库支持两种方案，也就是两种运行模式：
1.串行处理，也就是对于收到的批量的调用之后，一条一条处理，在第一条回调返回结果时再去执行第二条处理，依次类推指导所有调用处理完成为止。中间如果出现异常可以选择继续执行或中断返回整个处理结果。
2.串行处理，利用.net4.0提供的并行能力，使用任务处理批量的异步调用，并行库完成了一些同步机制，可以在全部单条调用结果返回时执行返回批量调用的结果。

串行方式可能执行时间比较长（与批量的条数有关），而串行方式可能需要很多线程并行参与，需要线程切换和同步比较多。对于一些性能要求比较高的推荐使用串行方式，对于一些要求返回结果比较快的推荐并行方式。一般RPC都属于IO密集型操作，而且每条之间比较独立，所以很适合任务处理。

运行结果：

流水线开始...
Proc:0 OK
Proc:1 OK
Proc:2 OK
Proc:3 OK
Proc:4 OK
Proc:5 OK
Proc:6 OK
Proc:7 OK
Proc:8 OK
Proc:9 OK
Proc:10 OK
Proc:11 OK
Proc:12 OK
Proc:13 OK
Proc:14 OK
Proc:15 OK
Proc:16 OK
Proc:17 OK
Proc:18 OK
Proc:19 OK
Proc:20 OK
Proc:21 OK
Proc:22 OK
Proc:23 OK
Proc:24 OK
Proc:25 OK
Proc:26 OK
Proc:27 OK
Proc:28 OK
Proc:29 OK
返回最终结果：100
返回最终结果：101
返回最终结果：102
返回最终结果：103
返回最终结果：104
返回最终结果：105
返回最终结果：106
返回最终结果：107
返回最终结果：108
返回最终结果：109
返回最终结果：110
返回最终结果：111
返回最终结果：112
返回最终结果：113
返回最终结果：114
返回最终结果：115
返回最终结果：116
返回最终结果：117
返回最终结果：118
返回最终结果：119
返回最终结果：120
返回最终结果：121
返回最终结果：122
返回最终结果：123
返回最终结果：124
返回最终结果：125
返回最终结果：126
返回最终结果：127
返回最终结果：128
返回最终结果：129
00:00:00.51

源代码提供下载

本文链接

【经典问题】现代操作系统经典问题回顾（哲学家就餐问题C#实现）

2010-08-21T13:10:00Z

在1971年，著名的计算机科学家艾兹格·迪科斯彻提出了一个同步问题，即假设有五台计算机都试图访问五份共享的磁带驱动器。稍后，这个问题被托尼·霍尔重新表述为哲学家就餐问题。这个问题可以用来解释死锁和资源耗尽。

哲学家就餐问题描述：五个哲学家围坐在一张圆桌周围，每个哲学家面前都有一盘通心粉。由于通心粉很光滑，所以需要两把叉子才能夹住，相邻两个盘子之间放有一把叉子。哲学家的生活中有两种交替活动时段：即吃饭和思考（一种抽象而已）。当一个哲学家觉得饿了时，他就试图分两次去取其左边和右边的叉子，每次拿到一把，但不分次序。如果成功地得到了两把叉子，就开始吃饭，吃完后放下叉子继续思考。问题是为哲学家写一段描述其行为的程序，且决不会死锁。

源码：

// ************************************************************
// 在1971年，著名的计算机科学家艾兹格·迪科斯彻提出了一个同步问题，
// 即假设有五台计算机都试图访问五份共享的磁带驱动器。稍后，这个问
// 题被托尼·霍尔重新表述为哲学家就餐问题。这个问题可以用来解释死
// 锁和资源耗尽。
//
// 哲学家就餐问题描述：五个哲学家围坐在一张圆桌周围，每个哲学家面
// 前都有一盘通心粉。由于通心粉很光滑，所以需要两把叉子才能夹住，
// 相邻两个盘子之间放有一把叉子。哲学家的生活中有两种交替活动时段：
// 即吃饭和思考（一种抽象而已）。当一个哲学家觉得饿了时，他就试图
// 分两次去取其左边和右边的叉子，每次拿到一把，但不分次序。如果成功
// 地得到了两把叉子，就开始吃饭，吃完后放下叉子继续思考。问题是为
// 哲学家写一段描述其行为的程序，且决不会死锁。
//
// 国兴旺 2010/08/21
// ************************************************************

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;

namespace DiningPhilosophers
{
    /// <summary>
    /// 哲学家就餐问题是现代操作系统中很经典的问题。
    /// 一个哲学家的封装。
    /// 国兴旺 2010/08/21
    /// </summary>
    public class Philosopher : WorkerThread
    {
        public const int READY = 0;
        public const int EATING = 1;
        public const int THINKING = 2;
        public const int FINISHED = 3;

        public Philosopher(object data) : base(data) { }
        public delegate void StateSwitchedHandler(Object sender, StateSwitchedEventArgs args);
        public event StateSwitchedHandler StateSwitch;

        protected override void Run()
        {
            PhilosopherData pd = (PhilosopherData)Data;
            Random rnd = new Random(pd.PhilosopherId);
            StateSwitch(this, new StateSwitchedEventArgs(READY, pd));
            WaitHandle[] forks = new WaitHandle[] { pd.LeftFork, pd.RightFork };

            while (pd.TotalFood > 0)
            {
                // 如果两边的哲学家有拿着叉子的，则等待。
                WaitHandle.WaitAll(forks);
                // 否则，开始吃通心粉。
                StateSwitch(this, new StateSwitchedEventArgs(EATING, pd));
                // 饭吃掉一部分移除。
                pd.TotalFood -= pd.AmountToEat;
                Thread.Sleep(rnd.Next(100, 1000));// 模拟正在吃通心粉

                StateSwitch(this, new StateSwitchedEventArgs(THINKING, pd));
                // 放下左边和右边的叉子开始思考。
                pd.RightFork.ReleaseMutex();
                pd.LeftFork.ReleaseMutex();

                Thread.Sleep(rnd.Next(100, 1000));// 模拟正在思考
            }

            // 至此，通信粉都吃完了。
            StateSwitch(this, new StateSwitchedEventArgs(FINISHED, pd));
        }
    }

    /// <summary>
    /// 哲学家相当于一个线程，这是工作线程抽象类，作为对线程操作的封装。
    /// 国兴旺 2010/08/21
    /// </summary>
    public abstract class WorkerThread
    {
        private object _threadData;
        private Thread _rawThread;

        public object Data
        {
            get { return _threadData; }
            set { _threadData = value; }
        }

        public WorkerThread(object data)
        {
            _threadData = data;
        }

        public WorkerThread()
        {
            _threadData = null;
        }

        public void Start()
        {
            _rawThread = new Thread(new ThreadStart(this.Run));
            _rawThread.Start();
        }

        protected abstract void Run();
    }

    /// <summary>
    /// 封装哲学家数据的结构。
    /// 国兴旺 2010/08/21
    /// </summary>
    public struct PhilosopherData
    {
        public int PhilosopherId;   // 代表哲学家
        public Mutex RightFork;     // 代表右边的叉子
        public Mutex LeftFork;      // 代表左边的叉子
        public int AmountToEat;     // 吃掉的通心粉
        public int TotalFood;       // 盘中的总的通心粉
    }

    /// <summary>
    /// 事件：用来通知外部现在哲学家的状态。
    /// 国兴旺 2010/08/21
    /// </summary>
    public class StateSwitchedEventArgs : EventArgs
    {
        public int type;
        public PhilosopherData philosopherData;
        public StateSwitchedEventArgs(int t, PhilosopherData pd)
        {
            type = t;
            philosopherData = pd;
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;

namespace DiningPhilosophers
{
    class Program
    {
        static void Main(string[] args)
        {
            // 准备数据
            Mutex[] forks = new Mutex[N];
            for (int i = 0; i < N; i++)
            {
                forks[i] = new Mutex(false);// 开始时叉子放在桌子上，没有哲学家拿到。
            }

            Philosopher[] p = new Philosopher[N];
            for (int i = 0; i < N; i++)
            {
                PhilosopherData pd;
                pd.PhilosopherId = i;
                pd.RightFork = forks[(i + 1) % N];// 右边的叉子编号
                pd.LeftFork = forks[(i + N - 1) % N];// 左边的叉子编号
                pd.AmountToEat = N_EAT;// 暂时大锅饭，大家都一样。
                pd.TotalFood = N_TOTAL;// 暂时大锅饭，大家都一样。
                p[i] = new Philosopher(pd);
                p[i].StateSwitch +=
                    new Philosopher.StateSwitchedHandler(
                        (sender, data) =>
                        {
                            Console.WriteLine("Philosopher:{0} IS {1}.",
                                data.philosopherData.PhilosopherId,
                                TranslateState(data.type));
                        });
            }

            for (int i = 0; i < N; i++)
                p[i].Start();

            Console.ReadKey();
        }

        private static string TranslateState(int state)
        {
            switch (state)
            {
                case Philosopher.READY:
                    return "READY";
                case Philosopher.EATING:
                    return "EATING";
                case Philosopher.THINKING:
                    return "THINKING";
                case Philosopher.FINISHED:
                    return "FINISHED";
                default:
                    throw new Exception("*NOT* FOUND.");
            }
        }

        public const int N = 5;// 哲学家或叉子数目。
        public const int N_EAT = 2;// 每次吃掉的通心粉数量。
        public const int N_TOTAL = 20;// 盘中通心粉总数。
    }
}

运行结果：

Philosopher:0 IS READY.
Philosopher:0 IS EATING.
Philosopher:1 IS READY.
Philosopher:1 IS EATING.
Philosopher:3 IS READY.
Philosopher:2 IS READY.
Philosopher:4 IS READY.
Philosopher:1 IS THINKING.
Philosopher:4 IS EATING.
Philosopher:0 IS THINKING.
Philosopher:3 IS EATING.
Philosopher:3 IS THINKING.
Philosopher:4 IS THINKING.
Philosopher:2 IS EATING.
Philosopher:1 IS EATING.
Philosopher:1 IS THINKING.
Philosopher:3 IS EATING.
Philosopher:2 IS THINKING.
Philosopher:4 IS EATING.
Philosopher:3 IS THINKING.
Philosopher:0 IS EATING.
Philosopher:4 IS THINKING.
Philosopher:1 IS EATING.
Philosopher:1 IS THINKING.
Philosopher:4 IS EATING.
Philosopher:0 IS THINKING.
Philosopher:3 IS EATING.
Philosopher:4 IS THINKING.
Philosopher:2 IS EATING.
Philosopher:2 IS THINKING.
Philosopher:4 IS EATING.
Philosopher:3 IS THINKING.
Philosopher:0 IS EATING.
Philosopher:0 IS THINKING.
Philosopher:3 IS EATING.
Philosopher:4 IS THINKING.
Philosopher:3 IS THINKING.
Philosopher:1 IS EATING.
Philosopher:2 IS EATING.
Philosopher:2 IS THINKING.
Philosopher:0 IS EATING.
Philosopher:1 IS THINKING.
Philosopher:4 IS EATING.
Philosopher:4 IS THINKING.
Philosopher:0 IS THINKING.
Philosopher:2 IS EATING.
Philosopher:3 IS EATING.
Philosopher:3 IS THINKING.
Philosopher:1 IS EATING.
Philosopher:1 IS THINKING.
Philosopher:2 IS THINKING.
Philosopher:4 IS EATING.
Philosopher:0 IS EATING.
Philosopher:4 IS THINKING.
Philosopher:1 IS EATING.
Philosopher:1 IS THINKING.
Philosopher:1 IS EATING.
Philosopher:0 IS THINKING.
Philosopher:2 IS EATING.
Philosopher:2 IS THINKING.
Philosopher:1 IS THINKING.
Philosopher:3 IS EATING.
Philosopher:4 IS EATING.
Philosopher:4 IS THINKING.
Philosopher:2 IS EATING.
Philosopher:3 IS THINKING.
Philosopher:1 IS EATING.
Philosopher:2 IS THINKING.
Philosopher:0 IS EATING.
Philosopher:0 IS THINKING.
Philosopher:2 IS EATING.
Philosopher:1 IS THINKING.
Philosopher:3 IS EATING.
Philosopher:2 IS THINKING.
Philosopher:4 IS EATING.
Philosopher:3 IS THINKING.
Philosopher:0 IS EATING.
Philosopher:4 IS THINKING.
Philosopher:1 IS EATING.
Philosopher:1 IS THINKING.
Philosopher:4 IS EATING.
Philosopher:0 IS THINKING.
Philosopher:3 IS EATING.
Philosopher:3 IS THINKING.
Philosopher:0 IS EATING.
Philosopher:4 IS THINKING.
Philosopher:1 IS EATING.
Philosopher:1 IS THINKING.
Philosopher:4 IS EATING.
Philosopher:0 IS THINKING.
Philosopher:3 IS EATING.
Philosopher:3 IS THINKING.
Philosopher:0 IS EATING.
Philosopher:1 IS FINISHED.
Philosopher:4 IS THINKING.
Philosopher:0 IS THINKING.
Philosopher:3 IS EATING.
Philosopher:2 IS EATING.
Philosopher:4 IS FINISHED.
Philosopher:2 IS THINKING.
Philosopher:3 IS THINKING.
Philosopher:2 IS EATING.
Philosopher:3 IS FINISHED.
Philosopher:2 IS THINKING.
Philosopher:0 IS EATING.
Philosopher:0 IS THINKING.
Philosopher:2 IS EATING.
Philosopher:0 IS FINISHED.
Philosopher:2 IS THINKING.
Philosopher:2 IS FINISHED.

源码下载

本文链接

【基本原理】使用托管代码实现一个寄宿ASP.NET的HTTP服务器（上）

2010-07-31T04:22:00Z

在这两篇文章中我将带着大家实现一个简单的ASP.NET的寄宿环境，本文是第一部分，主要讲述一些原理性的内容，其中大多使用自己的通俗的语言描述一些概念和基础性的内容，为了给读者带来更多的认识，本文也解释了一些最原始的概念，有些内容是自己的总结，如有不对或理解不一致的地方请读者指出。唉，本人实在不善于写文章，写了只是为了总结一些。

1.ASP.NET的Pipeline模型

ASP.NET随着.NET Framework一起分发，从1.0开始就一直以IIS作为寄宿环境。ASP.NET更是一个HTTP的处理引擎，内部实现了一套Pipeline模型，实现流水线处理请求的设计，从构造上线文环境（HttpContext）开始，经过一系列的过滤器（HttpModule，至于如何安装网上已经有很多介绍，HttpModule类似win32下的钩子Hook，可以做一些过滤处理，很实用的），请求会被送达处理器（HttpHandler，这个处理器可以完成对这个请求的最终处理），最后再经过一些过滤器而通过寄宿环境返回给客户端。需要说明的是这个Pipeline是一些讲述ASP.NET Runtime的文章中经常提到的概念，学习win32的同学们千万不要把这个Pipeline理解成Windows下的匿名或命名管道，它们完全是两个不同的概念，最初学习时很容易混淆，虽然在IIS内处理请求时与ASP.NET的WORKER进程之间通信等很多地方采用了命名管道，但是他们也不是一回事。至于讲述ASP.NET中Pipeline详细的文章网上到处都是，这里只是提及而已。

2.IIS的寄宿ASP.NET的基本工作原理

这里提及一下IIS的进程模型，IIS的进程模型从IIS5到IIS6是一个很大的飞跃，主要是IIS6把http协议栈实现在了内核模式中，那就是http.sys协议型驱动程序。这对于Windows作为Http服务器的性能是一个很大的提升，http.sys完成了连接的管理和请求路由（根据配置路由给相应的工作进程处理，这个配置可根据IIS的配置动态调整），http.sys与tcp.sys类似都是内核级的协议驱动程序，http.sys构建在tcpip.sys之上，就像http使用tcp协议承载一样，但是tcpip.sys实现的不仅是tcp/ip协议栈，它实现了很多协议的处理。在IIS5中使用socket处理http协议，但是socket是在用户态下运行的，所以处理http请求时会有大量的CPU从用户态和核心态之间的切换过程，这种切换的代价还是很大的，这对于大并发的http请求是不适合的。socket（这里的socket确切的说应该是 win sock）依赖于tcpip.sys完成标准接口功能，而tcpip.sys运行在内核态。从Windows xp sp2和Windows server 2003以后的操作系统中，微软提供了http.sys，http.sys在处理请求时，只有对于有必要投递给WORKER进程的请求，http.sys才会把请求数据根据动态的路由表路由给相应的进程处理。而且http.sys还完成了以下工作：如果当前要路由的进程没有启动，那么它会缓存住这个请求（放入请求队列中），直到有工作进程处理这个请求它才会投递。毫不夸张的说IIS在http.sys出现以后才成为真正的Http服务器。

这里插一句：之前有人曾经问过java与.net相互调用有几种方式，之后有人会说使用webservice，socket等。从上文的分析来看这种说法可能不太合适，说socket不如说tcp或udp等准确。因为从上文我们就可以看出socket只不过是一种标准的编程接口，除此之外并不代表什么，它的作用只是使编程风格统一化，使用统一的模型使用tcp等协议，实际上在调用时完全可以一端使用socket，而另一端使用ndis模拟协议实现，但是估计没有人会这么干，因为已经有现成的东西可用了。
也就是说使用底层的驱动程序还有很多机制，例如本文说到的http.sys这也是使用底层协议的很好的例子。以后我可能会详细介绍ndis驱动模型，使用ndis可以模拟各种协议发送数据包。
　　还要插一句：说一说我们常说的网络端口是什么？例如http常用的80端口，那么80到底是什么啊，看过tcp协议详解的同学会马上注意到端口的这种概念是出现在传输层的，IP层只涉及到IP地址为止，而传输层协议，例如tcp，udp等都会加入一个端口号，这其实是标准协议里规定的，实际上端口号在操作系统中只是一种标识，协议驱动程序会根据端口号和更详细的信息进行路由，例如我们说某个应用程序监听了80端口，那么驱动程序就会把协议中具有80端口的请求路由给这个监听程序。说白了就是一种标识，实现时也没有复杂的数据结构。当然这些概念都已经标准化了。

2.托管的HttpListener类型

HttpListener是一个.net的类型，可以使用它在.net平台下实现一个http的服务器，这个类型有很多成员，这个同学们可以参考msdn的相关文档，这也不是本文的重点。HttpListener实际上是基于httpapi.dll的，那么httpapi.dll是做什么的呢？我理解这个dll就是win32下对于http.sys核心态驱动程序功能的一个用户态的封装而已，使用httpapi.dll的导出函数，用户程序可以从用户态切换到到内核态使用http.sys，这就像kernel32.dll中的很多函数一样，实现了内核态系统服务的调用。那么有了这个用户带的dll就好办了。而HttpListener正是这个dll在.net平台下的封装，这样.net也可以间接的使用http.sys了。这也就为构建.net下的http服务器成为可能，因为这些基础性的东西微软已经为我们做好了。无论从理论还是实际上来看IIS6和HttpListener处理请求的性能是相当的。

3.如何寄宿ASP.NET运行时环境

观察IIS寄宿Asp.net的原理，我们会发现，真正的托管代码是从构建HttpWorkerRequest对象开始的，可以理解为IIS搜集了http请求的大量信息，之后构造了托管的HttpWorkerRequest对象，这个对象也就是托管和非托管的过度的关键，而后HttpWorkerRequest再去生成HttpContext对象，而这个HttpContext就是贯穿于Asp.net的pipeline模型始终的上下文对象。在.net进程中如何寄宿Asp.net的运行时呢？我们可以使用微软专门为寄宿Asp.net运行时而提供的的ApplicationHost类型（位于System.Web.Hosting）。System.Web.Hosting这个名称空间中有很多类型来处理其他种进程寄宿Asp.net运行时。代码类似：

internal AspxNetEngine(String virtualAlias, String physicalDir)
        {
            m_VirtualAlias = virtualAlias;
            m_PhysicalDirectory = physicalDir;

            Console.WriteLine("Creating a new AspxEngine.");

            //m_ExecutingEngine will be the actual object that the hosting API created for
            //us and so to execute a page in the Application we will call this object to
            //process requests
            m_ExecutingAppDomain = (AspxNetEngine)ApplicationHost.CreateApplicationHost(typeof(AspxNetEngine), m_VirtualAlias,m_PhysicalDirectory);

            Console.WriteLine("New AspxEngine created for alias " + m_VirtualAlias);
        }

ApplicationHost.CreateApplicationHost方法会创建一个新的应用程序域，并AspxNetEngine作为应用程序域通信的对象，所以AspxNetEngine必须是MarshalByRefObject。

基于以上资料我们就完全可以使用托管代码实现一个简单寄宿Asp.net的运行时的环境，这里的说的“简单”主要是比起IIS还有一些性能问题和其他方面的问题，下文将详细说明遇到的相关问题。其实这种实现网上有很多种，例如classin或vs自带的开发服务器，这种东西应用到实际的生产环境还是有问题的，IIS我们轻易不能放弃。

本文链接

【读书笔记】《框架设计（第2版）CLR Via C#》中两个比较有趣的知识点

2009-12-20T09:18:00Z

在阅读这本书时我发现很多值得思考和有趣的地方，例如：JR关于调用的参数和返回值的建议；位索引器示例；触发事件的事件安全；字符串格式化和字符串的驻留等。尤其是.NET的垃圾回收机制在这本书中讲的很详细。其中有两个知识点是让我感到收获很大的地方而且例子也很详细，我在这里就单独拿出来与大家分享，同时也作为知识点进行总结，这里讲没什么技术含量，大家别BS我。