The working set of a program is a collection of those pages in its virtual address space that have been recently referenced. It includes both shared and private data. The shared data includes pages that contain all instructions your application executes, including those in your DLLs and the system DLLs. As the working set size increases, memory demand increases.
程序的WorkingSet是其虚拟地址空间中的最近被引用过的Page集合。它包含shared和private的data。WorkingSet 是该进程所占用的物理内存的大小，可以使用SetProcessWorkingSetSize 函数设置该进程的最小、最大的WorkingSet。管理WorkingSet的一个简单规则是如果进程使用的物理内存（WorkingSet）超过了设定的最大的WorkingSet，一部分数据将会交换到page file。
下面对三者关系的阐述来源于：http://stackoverflow.com/questions/1984186/what-is-private-bytes-virtual-bytes-working-set
Private Bytes refer to the amount of memory that the process executable has asked for - not necessarily the amount it is actually using. They are "private" because they (usually) exclude memory-mapped files (i.e. shared DLLs). But - here's the catch - they don't necessarily exclude memory allocated by those files. There is no way to tell whether a change in private bytes was due to the executable itself, or due to a linked library. Private bytes are also not exclusively physical memory; they can be paged to disk or in the standby page list (i.e. no longer in use, but not paged yet either).
Working Set refers to the total physical memory (RAM) used by the process. However, unlike private bytes, this also includes memory-mapped files and various other resources, so it's an even less accurate measurement than the private bytes. This is the same value that gets reported in Task Manager's "Mem Usage" and has been the source of endless amounts of confusion in recent years. Memory in the Working Set is "physical" in the sense that it can be addressed without a page fault; however, the standby page list is also still physically in memory but not reported in the Working Set, and this is why you might see the "Mem Usage" suddenly drop when you minimize an application.
Virtual Bytes are the total virtual address space occupied by the entire process. This is like the working set, in the sense that it includes memory-mapped files (shared DLLs), but it also includes data in the standby list and data that has already been paged out and is sitting in a pagefile on disk somewhere. The total virtual bytes used by every process on a system under heavy load will add up to significantly more memory than the machine actually has.
So the relationships are:
•Private Bytes are what your app has actually allocated, but include pagefile usage;
Private Bytes是应用实际分配的内存数量，既包括在物理内存中的，也包括pagefile中的；linked dll分配的内存是不包含在private Bytes的。
•Working Set is the non-paged Private Bytes plus memory-mapped files;
Working Set是在物理内存中的Private Bytes加上memory-mapped files，是该进程所占用的物理内存大小；
•Virtual Bytes are the Working Set plus paged Private Bytes and standby list.
Virtual Bytes是Working Set加上paged Private Bytes 和standby list，是进程所占用的所有虚拟地址空间大小；
There's another problem here; just as shared libraries can allocate memory inside your application module, leading to potential false positives reported in your app's Private Bytes, your application may also end up allocating memory inside the shared modules, leading to false negatives. That means it's actually possible for your application to have a memory leak that never manifests itself in the Private Bytes at all. Unlikely, but possible.
Private Bytes are a reasonable approximation of the amount of memory your executable is using and can be used to help narrow down a list of potential candidates for a memory leak; if you see the number growing and growing constantly and endlessly, you would want to check that process for a leak. This cannot, however, prove that there is or is not a leak.
另外一篇介绍Windows Virtual Memory的文章是http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx
关于Memory Leak的一篇：http://msdn.microsoft.com/en-us/library/dd744766%28VS.85%29.aspx