第二、__declspec(dllexport)定義的導出多用于同一編譯器的隱式鏈接（靜態調用），而.def導出函數可以確定導出的函數名不會因為不同的編譯器而不同，可用于其它開發工具的調用。

有了上面的知識,我們再看JNI環境下的問題。

JNI定義了關鍵字JNIEXPORT，用于實現DLL中函數的導出的。實際在JNI中，JNIEXPORT被定義為，#define JNIEXPORT __declspec(dllexport)，也就是說JNI默認的導出函數使用dllexport方式。我們知道，使用使用dllexport方式產生的導出函數名會根據編譯器發生變化，在這種情況下，當Java程序通過Native接口調用DLL本地方法時，可能會發生找不到導出函數的問題。所以，在JNI的情況下，因此最好是定義一個.def文件來指明導出函數，以避免發生UnSatisfiedLinkedException錯誤 。

       Windows Native的c++應用大量使用了DLL技術。"動態鏈接"這幾字指明了DLLs是如何工作的。對于常規的函數庫，鏈接器從中拷貝它需要的所有庫函數，并把確切的函數地址傳送給調用這些函數的程序。而對于DLLs，函數儲存在一個獨立的動態鏈接庫文件中。在創建Windows程序時，鏈接過程并不把DLLs文件鏈接到程序上。直到程 序運行并調用一個DLLs中的函數時，該程序才要求這個函數的地址。此時Windows才在DLLs中尋找被調用函數，并把它的地址傳送給調用程序。采用這種方法，DLLs達到了復用代碼的極限。

      對于DLL, 關鍵一點是，所有run on windows system 的程序可以共用同一個DLL庫，從而達到最大限度的代碼復用。并且，由于DLL并不拷貝它需要的所有庫函數 ， 這樣的話Native的C++程序 executable image size 會比較小。

      從modularity的角度，如果要在Java的應用里尋找相對應的DLL的概念，我們會自然地想到jar包。JAR包可以被 Class Loader動態裝載進JVM, 不過要幾點區別需要說明的是：

第一、從本質上來講，JAR包是存在于磁盤上的一些data而已(由JVM解釋執行)，而DLL是executable 的image。

第二、Class Data Sharing (CDS)作為一個新的feature,在Java5才被引入，其做法就是：把 system jar 文件打包成為"shared archive"，這些"shared archive"會作為memory-mapped in文件存在，共享于不同的JVM 進程間，以減少JVM的footprint,加快Java應用的啟動時間。

            值得一提的是：兩者都有所謂的HELL問題(JAR HELL vs DLL HELL)，新老版本的兼容問題始終讓人頭疼。

詳見解釋：

http://en.wikipedia.org/wiki/DLL_hell

http://en.wikipedia.org/wiki/JAR_hell#JAR_hell

文章將從兩個方面進行闡述:

1. 使用 C++ 語言來描述 Monitor Object 設計模式。Java 對于這樣一個典型的模式做了很好的語言層面的封裝，因此對于 Java 的開發者來說，很多關于該模式本身的東西被屏蔽掉了。本文試圖使用 Native C++ 語言，幫助讀者從本質上對 Monitor object 設計模式有一個更全面的認識。
2. 結合 C++ 版本的 Monitor Object 設計模式，引領讀者對于 Java 同步機制有一個更深刻的認識，幫助讀者正確有效地使用 Java 同步機制。

class Window
{

public:
  virtual void  oops()
  {
    cout<<"Window oops"<<endl;
  }
public:
  int height;
  int width;
};
class TextWindow : public Window
{

public:
  virtual void  oops()
  {
    cout<<"TextWindow oops"<<cursorLocation<<endl;
  }
public:
  int cursorLocation;
};

main()
{
  Window win;
  Window* tWin;
  TextWindow * tWinPtr;

  tWinPtr = new TextWindow;
  tWin = tWinPtr;
  
  win.oops();
  tWin->oops();
}

類TextWindow繼承與類Window。我想程序運行的結果，大多數熟悉C++的人都會知道，
win.oops()最終調用的是父類oops函數，而tWin->oops()調用的是子類TextWindow的函數。
通過這個例子，我們先總結一下c++中的多態調用規則：
第一、對于指針和引用類型，當消息調用的成員函數有可能被重寫時，最終被選擇調用的成員函數由消息接收者的動態類型確定(注意：在OO概念中，對某個對象成員函數進行調用，常常稱為給該對象發送消息，該對象就是消息的接收者）。
      如上例：tWin->oops(),由于tWin的動態類型是子類TextWindow,而不是Windows,所以tWin->oops()調用的是子類TextWindow的函數。
第二、對于其它的變量，對虛擬函數調用綁定完全由該變量的靜態類型確定（即該變量的聲明），而不是該變量的真實類型確定。
     如上例：win.oops(),由于win的聲明類型為Window類,所以其結果調用的是父類oops函數。
二） 探討。
     接下來，我們要看的問題是，在c++中，為什么對于多態規則(或者說是動態函數綁定規則)，做出了兩中不同的劃分，即：只有指針與引用類型，才進行函數的后期動態綁定，也就是多態。這或許也是許多c++初學者非常迷惑的地方。這種規則的不一致性，的確給c++的語法造成一定的復雜性。而這在Java，或者C#中是沒有的，后面我們會涉及到。
      我們先來看例子。 

void f()
{
  Window  win;
  Window* tWinPtr;
  
  tWinPtr = new TextWindow;
  win     = *tWinPtr;//what's problem happen
   
  win.oops(); //what's problem happen
  tWinPtr->oops();
}

      在這里,如果我們假設，c++的函數動態綁定規則是一致的，看看會發生什么問題???
      現在win被聲明為Window類型，然而其真實的類型為TextWindow(因為win=*tWinPtr),由于我們的假設，win現在是允許進行動態函數綁定的，所以當執行win.oops()時，實際上是調用子類TextWindow的成員函數。
     現在，我們有必要來審視一下win變量的內存布局。由于win變量是在棧上聲明的變量，其內存也是從棧進行分配（這是c++從c語言那里繼承過來的優良特質，從棧上分配內存空間比動態分配內存有更好的執行速度），c++標準規定：給win變量分配內存空間的大小，由其靜態的類型確定，即應該是Window類所使用的內存空間大小。在這種情況下，當執行win=*tWinPtr時，什么會發生？如下圖：

在默認的拷貝構造函數情況下，信息會出現丟失，這就是著名的slicing off現象。結果，變量cursorLocation在win的內存空間里丟失了。然而，問題是：在我們假設下，我們要求win.oops()導致TextWindow的成員函數調用，而在這個函數中，訪問到的cursorLocation變量是不存在！win.oops()調用將導致內存違例！
      到這里，我們可以總結一下：c++標準基于的其特定的內存分配規則，給出了以上，我們在前一節總結出的函數動態綁定規則。
三） 深入。
      當然，我們也可以說，c++也可以通過改變其內存分配規則，來給出一個一致性的函數動態綁定規則。比如：可以考慮在給win變量分配內存空間時，考慮其所有子類需求，然后分配最大數量的內存空間給win變量。這種做法可行性很差，對于編譯器而言，需要掃描整個程序(確定該類的所有子類)，才能確定最大的內存空間是多少。在使用類庫或者框架的情況下，會引起整個類庫，框架的重新編譯，這是得不償失的！而這種做法，在oo的語言中，基本上是沒有的。這也是c++不得不基于其現有的內存管理機制，而對多態規則作出的不一致的解釋。
    對于這個c++現有的內存管理機制,我們如果從另外角度去理解的話,是很合理的。當win=*tWinPtr發生
時，我們可以類似地認為：好比一個float類型的數賦給了一個interger類型的變量，其結果當然是float的值被截斷了。
    我們再來看其它語言，Java（或者C#）是怎么解決的。
    最重要的一點是，在Java(C#)中只有引用的概念，所以在棧上聲明的類的變量，只需要分配一個指針大小的內存空間就行了，而不需要給該變量分配空間來保存變量內容本身，這其實就是我們現在看到的c++中指針和引用的情況。
    

class Base
{
public:
 virtual void f(int x);
};
class Derived: public Base
{
public:
 virtual void f(double* pd);
};
int main()
{
  Derived* pd = new Derived();
  pd->f(10); //compile error!!!
}

         當我們編譯pd->f(10)操作時，編譯器報錯。按照我們常規的理解是：父類的函數void f(int x)與子類的函數void f(double*pd)，由于參數類型不同，其函數簽名也是不一樣的，按照這樣的邏輯，在這個類繼承體系中，這兩個函數完全應該是互不隱藏的，我們完全可以認為是符合overloaded規則的兩個函數。
        但是，在c++里，子類通過函數名字隱藏父類函數，而不是通過函數簽名！c++給出的解釋也是合理的：試想一種情況：你使用了別人寫的類庫，繼承其中的某個類，寫了你自己的子類。
如上面的例子，你的子類就是Derived,而類庫中的父類就是Base.當你根本不知道在父類中還有這樣一個f(int x)函數時，在調用子類Derived的f函數時，你犯了錯誤，參數類型傳成了int類型（或者不是你犯的錯誤，編譯器幫你自動轉化為int類型），結果是：程序可以正常運行，但是，執行的結果卻不是你所期望的，是f(int x)調用，而不是你自己的實現：f（double* pd)調用！
         這就是c++為什么通過函數名字隱藏父類函數的原因。
        說到這里，我們需要補充幾句：雖然c++在語言層面上給我們提供了這樣的保證，但是，子類hide父類的函數，這是一個非常不好的設計。從OO的角度出發，應該講求的是Liskov Substitution Principle。即：suntypes must be substitutable fro their base types.很顯然，當hide行為發生時，從接口的角度來講，子類與父類是不能互為替代的。父類的protected or public的方法，應該很自然地由其所有子類所繼承，而不是被隱藏。隱藏行為的發生，相當于在這套繼承體系中開的一個后門。很顯然，C++幫助我們自動隱藏了父類的方法，但是，作為程序開發的我們，應該意識到這一點，也應該避免這樣的設計。
二、c++的per-class allocator語法規則
          在D&E of C++一書中，Stroustrup給出了幾點c++提供per-class allocator的理由，這些理由也是我們使用class level的allocator的原因，所以，有必要我們總結一下：
第一、許多程序應用，需要在運行的過程中，大量地Create和Delete對象。這些對象，諸如：tree nodes,linked list nodes，messages等等。如果在傳統的heap完成這些對象的創建，銷毀，由于大量的內存申請，釋放，勢必會造成內存碎片。這種情況下，我們需要對內存分配進行細粒度的控制。
第二、一些應用需要長時間跑在內存受限的裝置上，這也需要我們對內存分配進行細粒度的控制，而不是無限制地分配，釋放。
主要基于以上的兩點，c++提供了per-class allocator語言支持。
如下例：

class X
{
public:
  void* operator new(size_t sz); //allocate sz bytes
  void  operator delete(void* p) //free p;
};

      new操作符函數負責對象X的內存分配。對這樣一個語法規則，我們好奇的是，為什么聲明了一個我們從來都不使用的參數size_t sz.我們的使用語法如下： X* px = new X;
C++也給出了解釋：per-class allocator機制將適用整個類的繼承體系。例如：

class Y: public X //ojects of class Y are also allocated using X::operator new
{
  //
  // 
};

        對于子類Y,其內存分配函數也是X::operator new()。但是，在這里，內存分配的大小，不應該是sizeof(X),而是sizeof(Y).問題的關鍵在這里：C++通過提供多余的參數size_t sz，而給開發者提供了更大的靈活性，也即：per-class allocator是面向類的繼承體系的內存管理機制，而不單單是面向單個類。
三、Koenig Lookup機制。
        大家對Andrew Koenig應該很熟悉，c++大牛，是AT&T公司Shannon實驗室大規模編程研究部門中的成員，同時他也是C++標準委員會的項目編輯。他擁有超過30年的編程經驗，其中有15年的C++使用經驗。
        Koenig Lookup，就是以Andrew Koenig命名的查找規則。在看這個定義之前，我們先弄清楚函數所在的域的分類，一般來講，分為：
1：類域（函數作為某個類的成員函數（靜態或非靜態））
2：名字空間域
3：全局域（即C++默認的namespace)
        而Koenig Lookup機制，就是當編譯器對無限定域的函數調用進行名字查找時，除了當前名字空間域以外，也會把函數參數類型所處的名字空間加入查找的范圍。
如下例：

#include <iostream>
using namespace std;
namespace Koenig
{
    class MyArg
    {
    public:
         ostream& print(ostream& out) const
         {
            out<<"this is MyArg."<<endl;
         }
    };
 
    inline ostream& operator<<(ostream& out, const MyArg& myArg)
    {
         return myArg.print(out);
    }
}
 
int main()
{
    Koenig::MyArg myArg;
    cout<<myArg;
    return 0;
}

       如上的代碼，使用operator<<操作符函數，打印對象的狀態，但是函數ostream& operator<<(ostream& out, const MyArg& myArg) 的定義域是處于名字空間Koenig中，為什么編譯器在解析main函數（全局域）里面的operator<<調用時，它能夠正確定位到Koenig名字空間里面的operator<<？這是因為根據Koenig查找規則，編譯器需要把參數類型MyArg所在的名字空間Koenig也加入對ostream& operator<<(ostream& out, const MyArg& myArg) 調用的名字查找范圍中。
        如果沒有Koenig查找規則，我們就無法直接寫cout<<myArg;，而是需要寫類似Koenig::operator<<(std::cout, myArg); 這樣的代碼（使用完全限定名）。這樣的結果是，即不直觀也不方便。

        其實在C++里，提供了很多類似于Koenig查找規則的機制，以保證程序語法上的簡潔，明了。例如：許多的操作符函數，COPY構造函數。而這些，也是我們寫出專業的C++程序的基本。
未完待續:)

如圖所示：在IOCP中，主要有以下的參與者：
--》完成端口：是一個FIFO隊列，操作系統的IO子系統在IO操作完成后，會把相應的IO packet放入該隊列。
--》等待者線程隊列：通過調用GetQueuedCompletionStatus API，在完成端口上等待取下一個IO packet。
--》執行者線程組：已經從完成端口上獲得IO packet，在占用CPU進行處理。
除了以上三種類型的參與者。我們還應該注意兩個關聯關系，即：
--》IO Handle與完成端口相關聯：任何期望使用IOCP的方式來處理IO請求的，必須將相應的IO Handle與該完成端口相關聯。需要指出的時，這里的IO Handle，可以是File的Handle,或者是Socket的Handle。
--》線程與完成端口相關聯：任何調用GetQueuedCompletionStatus API的線程，都將與該完成端口相關聯。在任何給定的時候，該線程只能與一個完成端口相關聯，與最后一次調用的GetQueuedCompletionStatus為準。
二、高并發的服務器(基于socket)實現方法
        一般來講，實現基于socket的服務器，有三種實現的方式(thread per request的方式，我就不提了:))：
第一、線程池的方式。使用線程池來對客戶端請求進行服務。使用這種方式時，當客戶端對服務器的連接是短連接（所謂的短連接，即：客戶端對服務器不是長時間連接）時，是可以考慮的。但是，如若客戶端對服務器的連接是長連接時，我們需要限制服務器端的最大連接數目為線程池線程的最大數目，而這應用的設計本身來講，是不好的設計方式，scalability會存在問題。
第二、基于Select的服務器實現。其本質是，使用Select(操作系統提供的API)來監視連接是否可讀，可寫，或者是否出錯。相比于前一種方式，Select允許應用使用一個線程(或者是有限幾個線程)來監視連接的可讀寫性。當有連接可讀可寫時，應用可以以non-bolock的方式讀寫socket上的數據。使用Select的方式的缺點是，當Select所監視的連接數目在千的數量級時，性能會打折扣。這是因為操作系統內核需要在內部對這些Socket進行輪詢，以檢查其可讀寫性。另一個問題是：應用必須在處理完所有的可讀寫socket的IO請求之后，才能再次調用Select,進行下一輪的檢查，否則會有潛在的問題。這樣，造成的結果是，對一些請求的處理會出現饑餓的現象。
        一般common的做法是Select結合Leader-Follower設計模式使用。不過不管怎樣，Select的本質造成了其在Scalability的問題是不如IOCP，這也是很多high-scalabe的服務器采用IOCP的原因。
第三、IOCP實現高并發的服務器。IOCP是實現high-scalabe的服務器的首選。其特點我們專門在下一小姐陳述。
三、IOCP開發的幾個概念
第一、服務器的吞吐量問題。
      我們都知道，基于IOCP的開發是異步IO的，也正是這一技術的本質，決定了IOCP所實現的服務器的高吞吐量。
       我們舉一個及其簡化的例子，來說明這一問題。在網絡服務器的開發過程中，影響其性能吞吐量的，有很多因素，在這里，我們只是把關注點放在兩個方面，即：網絡IO速度與Disk IO速度。我們假設：在一個千兆的網絡環境下，我們的網絡傳輸速度的極限是大概125M/s，而Disk IO的速度是10M/s。在這樣的前提下，慢速的Disk 設備會成為我們整個應用的瓶頸。我們假設線程A負責從網絡上讀取數據，然后將這些數據寫入Disk。如果對Disk的寫入是同步的，那么線程A在等待寫完Disk的過程是不能再從網絡上接受數據的，在寫入Disk的時間內，我們可以認為這時候Server的吞吐量為0(沒有接受新的客戶端請求)。對于這樣的同步讀寫Disk，一些的解決方案是通過增加線程數來增加服務器處理的吞吐量，即：當線程A從網絡上接受數據后，驅動另外單獨的線程來完成讀寫Disk任務。這樣的方案缺點是：需要線程間的合作，需要線程間的切換（這是另一個我們要討論的問題）。而IOCP的異步IO本質，就是通過操作系統內核的支持，允許線程A以非阻塞的方式向IO子系統投遞IO請求，而后馬上從網絡上讀取下一個客戶端請求。這樣，結果是：在不增加線程數的情況下，IOCP大大增加了服務器的吞吐量。說到這里，聽起來感覺很像是DMA。的確，許多軟件的實現技術，在本質上，與硬件的實現技術是相通的。另外一個典型的例子是硬件的流水線技術，同樣，在軟件領域，也有很著名的應用。好像話題扯遠了，呵呵:)
第二、線程間的切換問題。
         服務器的實現，通過引入IOCP，會大大減少Thread切換帶來的額外開銷。我們都知道，對于服務器性能的一個重要的評估指標就是：System\Context Switches，即單位時間內線程的切換次數。如果在每秒內，線程的切換次數在千的數量級上，這就意味著你的服務器性能值得商榷。Context Switches/s應該越小越好。說到這里，我們來重新審視一下IOCP。
     完成端口的線程并發量可以在創建該完成端口時指定（即NumberOfConcurrentThreads參數）。該并發量限制了與該完成端口相關聯的可運行線程的數目(就是前面我在IOCP簡介中提到的執行者線程組的最大數目)。當與該完成端口相關聯的可運行線程的總數目達到了該并發量，系統就會阻塞任何與該完成端口相關聯的后續線程的執行，直到與該完成端口相關聯的可運行線程數目下降到小于該并發量為止。最有效的假想是發生在有完成包在隊列中等待，而沒有等待被滿足，因為此時完成端口達到了其并發量的極限。此時，一個正在運行中的線程調用GetQueuedCompletionStatus時，它就會立刻從隊列中取走該完成包。這樣就不存在著環境的切換，因為該處于運行中的線程就會連續不斷地從隊列中取走完成包，而其他的線程就不能運行了。
     完成端口的線程并發量的建議值就是你系統CPU的數目。在這里，要區分清楚的是，完成端口的線程并發量與你為完成端口創建的工作者線程數是沒有任何關系的，工作者線程數的數目，完全取決于你的整個應用的設計（當然這個不宜過大，否則失去了IOCP的本意:)）。
第三、IOCP開發過程中的消息亂序問題。
     使用IOCP開發的問題在于它的復雜。我們都知道，在使用TCP時，TCP協議本身保證了消息傳遞的次序性，這大大降低了上層應用的復雜性。但是當使用IOCP時，問題就不再那么簡單。如下例：
  
       三個線程同時從IOCP中讀取Msg1, Msg2,與Msg3。由于TCP本身消息傳遞的有序性，所以，在IOCP隊列內，Msg1-Msg2-Msg3保證了有序性。三個線程分別從IOCP中取出Msg1,Msg2與Msg3,然后三個線程都會將各自取到的消息投遞到邏輯層處理。在邏輯處理層的實現，我們不應該假定Msg1-Msg2-Msg3順序，原因其實很簡單，在Time 1~Time 2的時間段內，三個線程被操作系統調度的先后次序是不確定的，所以在到達邏輯處理層，
Msg1,Msg2與Msg3的次序也就是不確定的。所以，邏輯處理層的實現，必須考慮消息亂序的情況，必須考慮多線程環境下的程序實現。
        在這里，我把消息亂序的問題單列了出來。其實在IOCP的開發過程中，相比于同步的方式，應該還有其它更多的難題需要解決，這也是與Select方式相比，IOCP的缺點，實現復雜度高。
結束語：
    ACE的Proactor Framework， 對windows平臺的IOCP做了基于Proactor設計模式的，面向對象的封裝，這在一定程度上簡化了應用開發的難度，是一個很好的異步IO的開發框架，推薦學習使用。 
Reference:
    Microsoft Technet,Inside I/O Completion Ports