青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

posts - 195,  comments - 30,  trackbacks - 0

 

C#的內(nèi)存管理:堆、棧、托管堆與指針

32位的Windows操作系統(tǒng)中,每個(gè)進(jìn)程都可以使用4GB的內(nèi)存,這得益于虛擬尋址技術(shù),在這4GB的內(nèi)存中存儲(chǔ)著可執(zhí)行代碼、代碼加載的DLL和程序運(yùn)行的所有變量,在C#中,虛擬內(nèi)存中有個(gè)兩個(gè)存儲(chǔ)變量的區(qū)域,一個(gè)稱為堆棧,一個(gè)稱為托管堆,托管堆的出現(xiàn)是.net不同于其他語(yǔ)言的地方,堆棧存儲(chǔ)值類型數(shù)據(jù),而托管堆存儲(chǔ)引用類型如類、對(duì)象,并受垃圾收集器的控制和管理。在堆棧中,一旦變量超出使用范圍,其使用的內(nèi)存空間會(huì)被其他變量重新使用,這時(shí)其空間中存儲(chǔ)的值將被其他變量覆蓋而不復(fù)存在,但有時(shí)候我們希望這些值仍然存在,這就需要托管堆來實(shí)現(xiàn)。我們用幾段代碼來說明其工作原理,假設(shè)已經(jīng)定義了一個(gè)類class1:

 

class1 object1;

 

object1=new class1();

 

第一句定義了一個(gè)class1的引用,實(shí)質(zhì)上只是在堆棧中分配了一個(gè)4個(gè)字節(jié)的空間,它將用來存府后來實(shí)例化對(duì)象在托管堆中的地址,在windows中這需要4個(gè)字節(jié)來表示內(nèi)存地址。第二句實(shí)例化object1對(duì)象,實(shí)際上是在托管堆中開僻了一個(gè)內(nèi)存空間來存儲(chǔ)類class1的一個(gè)具體對(duì)象,假設(shè)這個(gè)對(duì)象需要36個(gè)字節(jié),那么object1指向的實(shí)際上是在托管堆一個(gè)大小為36個(gè)字節(jié)的連續(xù)內(nèi)存空間開始的地址。由此也可以看出在C#編譯器中為什么不允許使用未實(shí)例化的對(duì)象,因?yàn)檫@個(gè)對(duì)象在托管堆中還不存在。當(dāng)對(duì)象不再使用時(shí),這個(gè)被存儲(chǔ)在堆棧中的引用變量將被刪除,但是從上述機(jī)制可以看出,在托管堆中這個(gè)引用指向的對(duì)象仍然存在,其空間何時(shí)被釋放取決垃圾收集器而不是引用變量失去作用域時(shí)。

 

在使用電腦的過程中大家可能都有過這種經(jīng)驗(yàn):電腦用久了以后程序運(yùn)行會(huì)變得越來越慢,其中一個(gè)重要原因就是系統(tǒng)中存在大量?jī)?nèi)存碎片,就是因?yàn)槌绦蚍磸?fù)在堆棧中創(chuàng)建和釋入變量,久而久之可用變量在內(nèi)存中將不再是連續(xù)的內(nèi)存空間,為了尋址這些變量也會(huì)增加系統(tǒng)開銷。在.net中這種情形將得到很大改善,這是因?yàn)橛辛死占鞯墓ぷ鳎占鲗?huì)壓縮托管堆的內(nèi)存空間,保證可用變量在一個(gè)連續(xù)的內(nèi)存空間內(nèi),同時(shí)將堆棧中引用變量中的地址改為新的地址,這將會(huì)帶來額外的系統(tǒng)開銷,但是,其帶來的好處將會(huì)抵消這種影響,而另外一個(gè)好處是,程序員將不再花上大量的心思在內(nèi)在泄露問題上。

 

當(dāng)然,C#程序中不僅僅只有引用類型的變量,仍然也存在值類型和其他托管堆不能管理的對(duì)象,如果文件名柄、網(wǎng)絡(luò)連接和數(shù)據(jù)庫(kù)連接,這些變量的釋放仍需要程序員通過析構(gòu)函數(shù)或IDispose接口來做

 

另一方面,在某些時(shí)候C#程序也需要追求速度,比如對(duì)一個(gè)含用大量成員的數(shù)組的操作,如果仍使用傳統(tǒng)的類來操作,將不會(huì)得到很好的性能,因?yàn)閿?shù)組在C#中實(shí)際是System.Array的實(shí)例,會(huì)存儲(chǔ)在托管堆中,這將會(huì)對(duì)運(yùn)算造成大量的額外的操作,因?yàn)槌死占鞒藭?huì)壓縮托管堆、更新引用地址、還會(huì)維護(hù)托管堆的信息列表。所幸的是C#中同樣能夠通過不安全代碼使用C++程序員通常喜歡的方式來編碼,在標(biāo)記為unsafe的代碼塊使用指針,這和在C++中使用指針沒有什么不同,變量也是存府在堆棧中,在這種情況下聲明一個(gè)數(shù)組可以使用stackalloc語(yǔ)法,比如聲明一個(gè)存儲(chǔ)有50個(gè)double類型的數(shù)組:

 

double* pDouble=stackalloc double[50]

 

stackalloc會(huì)給pDouble數(shù)組在堆棧中分配50個(gè)double類型大小的內(nèi)存空間,可以使用pDouble[0]*(pDouble+1)這種方式操作數(shù)組,與在C++中一樣,使用指針時(shí)必須知道自己在做什么,確保訪問的正確的內(nèi)存空間,否則將會(huì)出現(xiàn)無法預(yù)料的錯(cuò)誤。

 

掌握托管堆、堆棧、垃圾收集器和不安全代碼的工作原理和方式,將有助于你成為真正的優(yōu)秀C#程序員。

 

進(jìn)程中每個(gè)線程都有自己的堆棧,這是一段線程創(chuàng)建時(shí)保留下的地址區(qū)域。我們的棧內(nèi)存即在此。至于內(nèi)存,我個(gè)人認(rèn)為在未用new定義時(shí),堆應(yīng)該就是未保留提交的自由空間,new的功能是在這些自由空間中保留(并提交?)出一個(gè)地址范圍

 

(Stack)是操作系統(tǒng)在建立某個(gè)進(jìn)程時(shí)或者線程(在支持多線程的操作系統(tǒng)中是線程)為這個(gè)線程建立的存儲(chǔ)區(qū)域,該區(qū)域具有FIFO的特性,在編譯的時(shí)候可以指定需要的Stack的大小。在編程中,例如C/C++中,所有的局部變量都是從棧中分配內(nèi)存空間,實(shí)際上也不是什么分配,只是從棧頂向上用就行,在退出函數(shù)的時(shí)候,只是修改棧指針就可以把棧中的內(nèi)容銷毀,所以速度最快。  

 堆(Heap)是應(yīng)用程序在運(yùn)行的時(shí)候請(qǐng)求操作系統(tǒng)分配給自己內(nèi)存,一般是申請(qǐng)/給予的過程,C/C++分別用malloc/New請(qǐng)求分配Heap,用free/delete銷毀內(nèi)存。由于從操作系統(tǒng)管理的內(nèi)存分配所以在分配和銷毀時(shí)都要占用時(shí)間,所以用堆的效率低的多!但是堆的好處是可以做的很大,C/C++對(duì)分配的Heap是不初始化的。  

 Java中除了簡(jiǎn)單類型(int,char等)都是在堆中分配內(nèi)存,這也是程序慢的一個(gè)主要原因。但是跟C/C++不同,Java中分配Heap內(nèi)存是自動(dòng)初始化的。在Java中所有的對(duì)象(包括intwrapper   Integer)都是在堆中分配的,但是這個(gè)對(duì)象的引用卻是在Stack中分配。也就是說在建立一個(gè)對(duì)象時(shí)從兩個(gè)地方都分配內(nèi)存,在Heap中分配的內(nèi)存實(shí)際建立這個(gè)對(duì)象,而在Stack中分配的內(nèi)存只是一個(gè)指向這個(gè)堆對(duì)象的指針(引用)而已。

 

.NET的所有技術(shù)中,最具爭(zhēng)議的恐怕是垃圾收集(Garbage CollectionGC)了。作為.NET框架中一個(gè)重要的部分,托管堆和垃圾收集機(jī)制對(duì)我們中的大部分人來說是陌生的概念。在這篇文章中將要討論托管堆,和你將從中得到怎樣的好處。

  為什么要托管堆?

  .NET框架包含一個(gè)托管堆,所有的.NET語(yǔ)言在分配引用類型對(duì)象時(shí)都要使用它。像值類型這樣的輕量級(jí)對(duì)象始終分配在棧中,但是所有的類實(shí)例和數(shù)組都被生成在一個(gè)內(nèi)存池中,這個(gè)內(nèi)存池就是托管堆。

  垃圾收集器的基本算法很簡(jiǎn)單:

  將所有的托管內(nèi)存標(biāo)記為垃圾

  尋找正被使用的內(nèi)存塊,并將他們標(biāo)記為有效

  釋放所有沒有被使用的內(nèi)存塊

  整理堆以減少碎片

  托管堆優(yōu)化

  看上去似乎很簡(jiǎn)單,但是垃圾收集器實(shí)際采用的步驟和堆管理系統(tǒng)的其他部分并非微不足道,其中常常涉及為提高性能而作的優(yōu)化設(shè)計(jì)。舉例來說,垃圾收集遍歷整個(gè)內(nèi)存池具有很高的開銷。然而,研究表明大部分在托管堆上分配的對(duì)象只有很短的生存期,因此堆被分成三個(gè)段,稱作generations。新分配的對(duì)象被放在generation 0中。這個(gè)generation是最先被回收的——在這個(gè)generation中最有可能找到不再使用的內(nèi)存,由于它的尺寸很小(小到足以放進(jìn)處理器的L2 cache中),因此在它里面的回收將是最快和最高效的。

  托管堆的另外一種優(yōu)化操作與locality of reference規(guī)則有關(guān)。該規(guī)則表明,一起分配的對(duì)象經(jīng)常被一起使用。如果對(duì)象們?cè)诙阎形恢煤芫o湊的話,高速緩存的性能將會(huì)得到提高。由于托管堆的天性,對(duì)象們總是被分配在連續(xù)的地址上,托管堆總是保持緊湊,結(jié)果使得對(duì)象們始終彼此靠近,永遠(yuǎn)不會(huì)分得很遠(yuǎn)。這一點(diǎn)與標(biāo)準(zhǔn)堆提供的非托管代碼形成了鮮明的對(duì)比,在標(biāo)準(zhǔn)堆中,堆很容易變成碎片,而且一起分配的對(duì)象經(jīng)常分得很遠(yuǎn)。

  還有一種優(yōu)化是與大對(duì)象有關(guān)的。通常,大對(duì)象具有很長(zhǎng)的生存期。當(dāng)一個(gè)大對(duì)象在.NET托管堆中產(chǎn)生時(shí),它被分配在堆的一個(gè)特殊部分中,這部分堆永遠(yuǎn)不會(huì)被整理。因?yàn)橐苿?dòng)大對(duì)象所帶來的開銷超過了整理這部分堆所能提高的性能。

  關(guān)于外部資源(External Resources)的問題

  垃圾收集器能夠有效地管理從托管堆中釋放的資源,但是資源回收操作只有在內(nèi)存緊張而觸發(fā)一個(gè)回收動(dòng)作時(shí)才執(zhí)行。那么,類是怎樣來管理像數(shù)據(jù)庫(kù)連接或者窗口句柄這樣有限的資源的呢?等待,直到垃圾回收被觸發(fā)之后再清理數(shù)據(jù)庫(kù)連接或者文件句柄并不是一個(gè)好方法,這會(huì)嚴(yán)重降低系統(tǒng)的性能。

  所有擁有外部資源的類,在這些資源已經(jīng)不再用到的時(shí)候,都應(yīng)當(dāng)執(zhí)行Close或者Dispose方法。從Beta2(譯注:本文中所有的Beta2均是指.NET Framework Beta2,不再特別注明)開始,Dispose模式通過IDisposable接口來實(shí)現(xiàn)。這將在本文的后續(xù)部分討論。

  需要清理外部資源的類還應(yīng)當(dāng)實(shí)現(xiàn)一個(gè)終止操作(finalizer)。在C#中,創(chuàng)建終止操作的首選方式是在析構(gòu)函數(shù)中實(shí)現(xiàn),而在Framework層,終止操作的實(shí)現(xiàn)則是通過重載System.Object.Finalize 方法。以下兩種實(shí)現(xiàn)終止操作的方法是等效的:

  ~OverdueBookLocator()

  {

   Dispose(false);

  }

  和:

  public void Finalize()

  {

   base.Finalize();

   Dispose(false);

  }

  在C#中,同時(shí)在Finalize方法和析構(gòu)函數(shù)實(shí)現(xiàn)終止操作將會(huì)導(dǎo)致錯(cuò)誤的產(chǎn)生。

  除非你有足夠的理由,否則你不應(yīng)該創(chuàng)建析構(gòu)函數(shù)或者Finalize方法。終止操作會(huì)降低系統(tǒng)的性能,并且增加執(zhí)行期的內(nèi)存開銷。同時(shí),由于終止操作被執(zhí)行的方式,你并不能保證何時(shí)一個(gè)終止操作會(huì)被執(zhí)行。

  內(nèi)存分配和垃圾回收的細(xì)節(jié)

  對(duì)GC有了一個(gè)總體印象之后,讓我們來討論關(guān)于托管堆中的分配與回收工作的細(xì)節(jié)。托管堆看起來與我們已經(jīng)熟悉的C++編程中的傳統(tǒng)的堆一點(diǎn)都不像。在傳統(tǒng)的堆中,數(shù)據(jù)結(jié)構(gòu)習(xí)慣于使用大塊的空閑內(nèi)存。在其中查找特定大小的內(nèi)存塊是一件很耗時(shí)的工作,尤其是當(dāng)內(nèi)存中充滿碎片的時(shí)候。與此不同,在托管堆中,內(nèi)存被組制成連續(xù)的數(shù)組,指針總是巡著已經(jīng)被使用的內(nèi)存和未被使用的內(nèi)存之間的邊界移動(dòng)。當(dāng)內(nèi)存被分配的時(shí)候,指針只是簡(jiǎn)單地遞增——由此而來的一個(gè)好處是,分配操作的效率得到了很大的提升。

  當(dāng)對(duì)象被分配的時(shí)候,它們一開始被放在generation 0中。當(dāng)generation 0的大小快要達(dá)到它的上限的時(shí)候,一個(gè)只在generation 0中執(zhí)行的回收操作被觸發(fā)。由于generation 0的大小很小,因此這將是一個(gè)非常快的GC過程。這個(gè)GC過程的結(jié)果是將generation 0徹底的刷新了一遍。不再使用的對(duì)象被釋放,確實(shí)正被使用的對(duì)象被整理并移入generation 1中。

  當(dāng)generation 1的大小隨著從generation 0中移入的對(duì)象數(shù)量的增加而接近它的上限的時(shí)候,一個(gè)回收動(dòng)作被觸發(fā)來在generation 0generation 1中執(zhí)行GC過程。如同在generation 0中一樣,不再使用的對(duì)象被釋放,正在被使用的對(duì)象被整理并移入下一個(gè)generation中。大部分GC過程的主要目標(biāo)是generation 0,因?yàn)樵?/span>generation 0中最有可能存在大量的已不再使用的臨時(shí)對(duì)象。對(duì)generation 2的回收過程具有很高的開銷,并且此過程只有在generation 0generation 1GC過程不能釋放足夠的內(nèi)存時(shí)才會(huì)被觸發(fā)。如果對(duì)generation 2GC過程仍然不能釋放足夠的內(nèi)存,那么系統(tǒng)就會(huì)拋出OutOfMemoryException異常

  帶有終止操作的對(duì)象的垃圾收集過程要稍微復(fù)雜一些。當(dāng)一個(gè)帶有終止操作的對(duì)象被標(biāo)記為垃圾時(shí),它并不會(huì)被立即釋放。相反,它會(huì)被放置在一個(gè)終止隊(duì)列(finalization queue)中,此隊(duì)列為這個(gè)對(duì)象建立一個(gè)引用,來避免這個(gè)對(duì)象被回收。后臺(tái)線程為隊(duì)列中的每個(gè)對(duì)象執(zhí)行它們各自的終止操作,并且將已經(jīng)執(zhí)行過終止操作的對(duì)象從終止隊(duì)列中刪除。只有那些已經(jīng)執(zhí)行過終止操作的對(duì)象才會(huì)在下一次垃圾回收過程中被從內(nèi)存中刪除。這樣做的一個(gè)后果是,等待被終止的對(duì)象有可能在它被清除之前,被移入更高一級(jí)的generation中,從而增加它被清除的延遲時(shí)間。

  需要執(zhí)行終止操作的對(duì)象應(yīng)當(dāng)實(shí)現(xiàn)IDisposable接口,以便客戶程序通過此接口快速執(zhí)行終止動(dòng)作。IDisposable接口包含一個(gè)方法——Dispose。這個(gè)被Beta2引入的接口,采用一種在Beta2之前就已經(jīng)被廣泛使用的模式實(shí)現(xiàn)。從本質(zhì)上講,一個(gè)需要終止操作的對(duì)象暴露出Dispose方法。這個(gè)方法被用來釋放外部資源并抑制終止操作,就象下面這個(gè)程序片斷所演示的那樣:

  public class OverdueBookLocator: IDisposable

  {

   ~OverdueBookLocator()

   {

   InternalDispose(false);

   }

   public void Dispose()

   {

   InternalDispose(true);

   }

   protected void InternalDispose(bool disposing)

   {

   if(disposing)

   {

   GC.SuppressFinalize(this);

   // Dispose of managed objects if disposing.

   }

   // free external resources here

   }

  }

 

這些都是.NETCLR的概念,和C#沒多大關(guān)系。

使用基于CLR的語(yǔ)言編譯器開發(fā)的代碼稱為托管代碼。

托管堆是CLR中自動(dòng)內(nèi)存管理的基礎(chǔ)。初始化新進(jìn)程時(shí),運(yùn)行時(shí)會(huì)為進(jìn)程保留一個(gè)連續(xù)的地址空間區(qū)域。這個(gè)保留的地址空間被稱為托管堆。托管堆維護(hù)著一個(gè)指針,用它指向?qū)⒃诙阎蟹峙涞南乱粋€(gè)對(duì)象的地址。最初,該指針設(shè)置為指向托管堆的基址。

認(rèn)真看MSDN Library,就會(huì)搞清楚這些概念。

 

以下代碼說明的很形象:

 

//引用類型('class' 類類型)

class SomeRef { public int32 x;}

 

//值類型('struct')

struct SomeVal(pulic Int32 x;}

 

static void ValueTypeDemo()

{

 SomeRef r1=new SomeRef();//分配在托管堆

 SomeVal v1=new SomeVal();//堆棧上

 r1.x=5;//解析指針

 v1.x=5;//在堆棧上修改

 

 SomeRef r2=r1;//僅拷貝引用(指針)

 SomeVal v2=v1;//先在堆棧上分配,然后拷貝成員

 

 r1.x=8;//改變了r1,r2的值

 v1.x=9;//改變了v1,沒有改變v2

}

posted on 2011-04-08 15:10 luis 閱讀(567) 評(píng)論(0)  編輯 收藏 引用

只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


<2011年3月>
272812345
6789101112
13141516171819
20212223242526
272829303112
3456789

常用鏈接

留言簿(3)

隨筆分類

隨筆檔案

文章分類

文章檔案

友情鏈接

搜索

  •  

最新評(píng)論

閱讀排行榜

評(píng)論排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            欧美在线三级| 久久精品国产精品亚洲精品| 久久国产精品99国产精| 国产精品一区二区三区久久| 亚洲欧美日韩电影| 亚洲欧美日韩一区二区三区在线 | 欧美精品一区二区三区蜜桃| 免费成人激情视频| 亚洲高清成人| 亚洲区国产区| 欧美午夜电影一区| 久久精品夜色噜噜亚洲aⅴ| 欧美一区二区三区在线看| 狠狠88综合久久久久综合网| 91久久夜色精品国产九色| 亚洲理论电影网| 国产欧美精品一区aⅴ影院| 裸体女人亚洲精品一区| 欧美精品一区二区三区蜜桃| 欧美一区二区高清| 欧美激情视频在线免费观看 欧美视频免费一| 夜夜精品视频一区二区| 欧美一区二区日韩| 99国产精品| 欧美一二区视频| 亚洲每日更新| 香蕉av777xxx色综合一区| 91久久综合亚洲鲁鲁五月天| 亚洲一区二区免费看| 在线日韩视频| 亚洲一区bb| 亚洲美女av在线播放| 亚洲欧美综合一区| 99爱精品视频| 免费看的黄色欧美网站| 欧美亚洲专区| 欧美日韩三级在线| 麻豆9191精品国产| 国产精品久久久久91| 欧美日韩国产一区精品一区| 午夜亚洲激情| 欧美日韩精品一区二区| 久久综合色综合88| 国产精品久久久久久超碰| 欧美国产日韩亚洲一区| 国产一区二区黄| 亚洲香蕉伊综合在人在线视看| 亚洲国产一区二区a毛片| 亚洲欧美日韩专区| 亚洲午夜一区二区三区| 欧美国产三级| 欧美激情一区二区| 在线播放亚洲| 久久久精品欧美丰满| 销魂美女一区二区三区视频在线| 欧美精品一区二区三| 欧美国产综合| 亚洲黄一区二区三区| 久久精品国产99国产精品| 久久久久久久999| 国产精品婷婷| 午夜精品一区二区三区电影天堂| 亚洲一区尤物| 国产精品人人做人人爽| 亚洲天堂av图片| 午夜精品久久久久影视 | 亚洲欧美精品在线| 欧美日韩一区二区三区四区在线观看| 欧美承认网站| 亚洲国产精品123| 亚洲二区免费| 欧美中文日韩| 久久精品国产免费看久久精品| 国产欧美一区二区三区另类精品 | 国产精品爽黄69| 欧美一级理论片| 免费久久精品视频| 亚洲福利免费| 欧美精品在线一区二区| 日韩亚洲成人av在线| 亚洲综合精品四区| 国产午夜精品福利| 久久三级福利| 亚洲人成欧美中文字幕| 亚洲中字在线| 韩日精品视频| 欧美激情国产高清| 亚洲一区二区高清视频| 久久久久九九九| 最新日韩在线视频| 欧美午夜精品久久久| 欧美伊人影院| 亚洲精品国产无天堂网2021| 久久精品视频免费播放| 亚洲精品日韩在线观看| 国产精品chinese| 久久激情五月激情| 亚洲第一精品影视| 亚洲一区二区高清视频| 国内揄拍国内精品少妇国语| 欧美激情小视频| 欧美一区二区三区四区在线观看 | 国产精品入口尤物| 久久在线精品| 亚洲一区二区三区免费观看| 另类亚洲自拍| 亚洲午夜激情网站| 亚洲成在线观看| 国产精品毛片a∨一区二区三区| 久久久久久一区二区三区| 亚洲视频一二区| 亚洲精品一区二区在线观看| 蜜臀久久99精品久久久久久9| 亚洲男人的天堂在线| 亚洲精品一区二区三区樱花| 狠狠色丁香婷婷综合影院| 国产精品久久久久久久久久免费看 | 国产日韩欧美精品一区| 欧美巨乳在线| 模特精品在线| 久久久久久亚洲精品中文字幕 | 亚洲午夜精品| 亚洲精品日本| 99re6这里只有精品| 亚洲精品欧美精品| 亚洲第一天堂av| 一区二区三区在线高清| 国产日韩欧美精品综合| 国产视频一区在线观看一区免费| 国产精品入口日韩视频大尺度| 欧美色另类天堂2015| 欧美国内亚洲| 亚洲欧美日韩精品| 久久精品国产清高在天天线| 亚洲一区二区三区乱码aⅴ| 亚洲精品久久久久久久久| 国产综合一区二区| 国产精品毛片高清在线完整版| 欧美日韩激情小视频| 亚洲精品国产拍免费91在线| 亚洲国产毛片完整版 | 一区二区三区日韩在线观看| 欧美二区不卡| 久久久久久久久蜜桃| 久久精品论坛| 香蕉尹人综合在线观看| 一区二区三区波多野结衣在线观看| 国产精品高潮粉嫩av| 欧美韩日一区| 久久久久久成人| 亚洲一区二区三区免费在线观看 | 欧美国产精品| 欧美大片在线观看一区| 久久国产精品久久精品国产| 国产精品99久久不卡二区| 一区二区久久久久| 亚洲精品色婷婷福利天堂| 欧美成年人网站| 久久综合久色欧美综合狠狠| 久久精品国产成人| 欧美一区二区三区四区高清| 在线观看日韩www视频免费| 在线电影国产精品| 激情五月综合色婷婷一区二区| 国产视频在线观看一区| 伊人狠狠色丁香综合尤物| 国产亚洲成年网址在线观看| 国产精品免费网站| 欧美激情影音先锋| 欧美激情视频一区二区三区在线播放| 老牛嫩草一区二区三区日本| 欧美在线亚洲在线| 欧美高清一区二区| 欧美激情亚洲综合一区| 欧美激情区在线播放| 国产麻豆午夜三级精品| 国产午夜精品福利| 国内成+人亚洲+欧美+综合在线| 亚洲第一精品久久忘忧草社区| 影音先锋亚洲电影| 亚洲丶国产丶欧美一区二区三区| 国产毛片一区| 91久久久久久久久| 亚洲精品九九| 在线一区免费观看| 久久综合色88| 亚洲国产精品热久久| 亚洲日本中文字幕| 欧美在线播放一区二区| 久久婷婷久久一区二区三区| 玖玖玖国产精品| 国产精品毛片在线看| 国产亚洲观看| 亚洲盗摄视频| 欧美一区二区三区免费观看视频| 久久这里有精品15一区二区三区| 欧美a级片网| 午夜精品亚洲一区二区三区嫩草| 久久青草久久| 欧美日韩第一区|