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

陳碩的Blog

C++ 工程實踐(2):不要重載全局 ::operator new()

陳碩 (giantchen_AT_gmail)

Blog.csdn.net/Solstice

 

本文只考慮 Linux x86 平臺,服務(wù)端開發(fā)(不考慮 Windows 的跨 DLL 內(nèi)存分配釋放問題)。本文假定讀者知道 ::operator new() 和 ::operator delete() 是干什么的,與通常用的 new/delete 表達(dá)式有和區(qū)別和聯(lián)系,這方面的知識可參考侯捷先生的文章《池內(nèi)春秋》[1],或者這篇文章

C++ 的內(nèi)存管理是個老生常談的話題,我在《當(dāng)析構(gòu)函數(shù)遇到多線程》第 7 節(jié)“插曲:系統(tǒng)地避免各種指針錯誤”中簡單回顧了一些常見的問題以及在現(xiàn)代 C++ 中的解決辦法。基本上,按現(xiàn)代 C++ 的手法(RAII)來管理內(nèi)存,你很難遇到什么內(nèi)存方面的錯誤。“沒有錯誤”是基本要求,不代表“足夠好”。我們常常會設(shè)法優(yōu)化性能,如果 profiling 表明 hot spot 在內(nèi)存分配和釋放上,重載全局的 ::operator new() 和 ::operator delete() 似乎是一個一勞永逸好辦法(以下簡寫為“重載 ::operator new()”),本文試圖說明這個辦法往往行不通。

內(nèi)存管理的基本要求

如果只考慮分配和釋放,內(nèi)存管理基本要求是“不重不漏”:既不重復(fù) delete,也不漏掉 delete。也就說我們常說的 new/delete 要配對,“配對”不僅是個數(shù)相等,還隱含了 new 和 delete 的調(diào)用本身要匹配,不要“東家借的東西西家還”。例如:

  • 用系統(tǒng)默認(rèn)的 malloc() 分配的內(nèi)存要交給系統(tǒng)默認(rèn)的 free() 去釋放;
  • 用系統(tǒng)默認(rèn)的 new 表達(dá)式創(chuàng)建的對象要交給系統(tǒng)默認(rèn)的 delete 表達(dá)式去析構(gòu)并釋放;
  • 用系統(tǒng)默認(rèn)的 new[] 表達(dá)式創(chuàng)建的對象要交給系統(tǒng)默認(rèn)的 delete[] 表達(dá)式去析構(gòu)并釋放;
  • 用系統(tǒng)默認(rèn)的 ::operator new() 分配的的內(nèi)存要交給系統(tǒng)默認(rèn)的 ::operator delete() 去釋放;
  • 用 placement new 創(chuàng)建的對象要用 placement delete (為了表述方便,姑且這么說吧)去析構(gòu)(其實就是直接調(diào)用析構(gòu)函數(shù));
  • 從某個內(nèi)存池 A 分配的內(nèi)存要還給這個內(nèi)存池。
  • 如果定制 new/delete,那么要按規(guī)矩來。見 Effective C++ 相關(guān)條款。

做到以上這些不難,是每個 C++ 開發(fā)人員的基本功。不過,如果你想重載全局的 ::operator new(),事情就麻煩了。

重載 ::operator new() 的理由

Effective C++ 第三版第 50 條列舉了定制 new/delete 的幾點理由:

  • 檢測代碼中的內(nèi)存錯誤
  • 優(yōu)化性能
  • 獲得內(nèi)存使用的統(tǒng)計數(shù)據(jù)

這些都是正當(dāng)?shù)男枨?,文末我們將會看到,不重載 ::operator new() 也能達(dá)到同樣的目的。

::operator new() 的兩種重載方式

1. 不改變其簽名,無縫直接替換系統(tǒng)原有的版本,例如:

#include <new>

void* operator new(size_t size);

void operator delete(void* p);

用這種方式的重載,使用方不需要包含任何特殊的頭文件,也就是說不需要看見這兩個函數(shù)聲明。“性能優(yōu)化”通常用這種方式。

2. 增加新的參數(shù),調(diào)用時也提供這些額外的參數(shù),例如:

void* operator new(size_t size, const char* file, int line);  // 其返回的指針必須能被普通的 ::operator delete(void*) 釋放

void operator delete(void* p, const char* file, int line);  // 這個函數(shù)只在析構(gòu)函數(shù)拋異常的情況下才會被調(diào)用

然后用的時候是

Foo* p = new (__FILE, __LINE__) Foo;  // 這樣能跟蹤是哪個文件哪一行代碼分配的內(nèi)存

我們也可以用宏替換 new 來節(jié)省打字。用這第二種方式重載,使用方需要看到這兩個函數(shù)聲明,也就是說要主動包含你提供的頭文件。“檢測內(nèi)存錯誤”和“統(tǒng)計內(nèi)存使用情況”通常會用這種方式重載。當(dāng)然,這不是絕對的。

 

在學(xué)習(xí) C++ 的階段,每個人都可以寫個一兩百行的程序來驗證教科書上的說法,重載 ::operator new() 在這樣的玩具程序里邊不會造成什么麻煩。

不過,我認(rèn)為在現(xiàn)實的產(chǎn)品開發(fā)中,重載 ::operator new() 乃是下策,我們有更簡單安全的辦法來到達(dá)以上目標(biāo)。

現(xiàn)實的開發(fā)環(huán)境

作為 C++ 應(yīng)用程序的開發(fā)人員,在編寫稍具規(guī)模的程序時,我們通常會用到一些 library。我們可以根據(jù) library 的提供方把它們大致分為這么幾大類:

  1. C 語言的標(biāo)準(zhǔn)庫,也包括 Linux 編程環(huán)境提供的 Posix 系列函數(shù)。
  2. 第三方的 C 語言庫,例如 OpenSSL。
  3. C++ 語言的標(biāo)準(zhǔn)庫,主要是 STL。(我想沒有人在產(chǎn)品中使用 IOStream 吧?)
  4. 第三方的通用 C++ 庫,例如 Boost.Regex,或者某款 XML 庫。
  5. 公司其他團(tuán)隊的人開發(fā)的內(nèi)部基礎(chǔ) C++ 庫,比如網(wǎng)絡(luò)通信和日志等基礎(chǔ)設(shè)施。
  6. 本項目組的同事自己開發(fā)的針對本應(yīng)用的基礎(chǔ)庫,比如某三維模型的仿射變換模塊。

在使用這些 library 的時候,不可避免地要在各個 library 之間交換數(shù)據(jù)。比方說 library A 的輸出作為 library B 的輸入,而 library A 的輸出本身常常會用到動態(tài)分配的內(nèi)存(比如 std::vector<double>)。

如果所有的 C++ library 都用同一套內(nèi)存分配器(就是系統(tǒng)默認(rèn)的 new/delete ),那么內(nèi)存的釋放就很方便,直接交給 delete 去釋放就行。如果不是這樣,那就得時時刻刻記住“這一塊內(nèi)存是屬于哪個分配器,是系統(tǒng)默認(rèn)的還是我們定制的,釋放的時候不要還錯了地方”。

(由于 C 語言不像 C++ 一樣提過了那么多的定制性,C library 通常都會默認(rèn)直接用 malloc/free 來分配和釋放內(nèi)存,不存在上面提到的“內(nèi)存還錯地方”問題。或者有的考慮更全面的 C library 會讓你注冊兩個函數(shù),用于它內(nèi)部分配和釋放內(nèi)存,這就就能完全掌控該 library 的內(nèi)存使用。這種依賴注入的方式在 C++ 里變得花哨而無用,見陳碩寫的《C++ 標(biāo)準(zhǔn)庫中的allocator是多余的》。)

但是,如果重載了 ::operator new(),事情恐怕就沒有這么簡單了。

重載 ::operator new() 的困境

首先,重載 ::operator new() 不會給 C 語言的庫帶來任何麻煩,當(dāng)然,重載它得到的三點好處也無法讓 C 語言的庫享受到。

以下僅考慮 C++ library 和 C++ 主程序。

規(guī)則 1:絕對不能在 library 里重載 ::operator new()

如果你是某個 library 的作者,你的 library 要提供給別人使用,那么你無權(quán)重載全局 ::operator new(size_t) (注意這是上面提到的第一種重載方式),因為這非常具有侵略性:任何用到你的 library 的程序都被迫使用了你重載的 ::operator new(),而別人很可能不愿意這么做。另外,如果有兩個 library 都試圖重載 ::operator new(size_t),那么它們會打架,我估計會發(fā)生 duplicated symbol link error。干脆,作為 library 的編寫者,大家都不要重載 ::operator new(size_t) 好了。

那么第二種重載方式呢?首先,::operator new(size_t size, const char* file, int line) 這種方式得到的 void* 指針必須同時能被 ::operator delete(void*) 和 ::operator delete(void* p, const char* file, int line) 這兩個函數(shù)釋放。這時候你需要決定,你的 ::operator new(size_t size, const char* file, int line) 返回的指針是不是兼容系統(tǒng)默認(rèn)的 ::operator delete(void*)。

  • 如果不兼容(也就是說不能用系統(tǒng)默認(rèn)的 ::operator delete(void*) 來釋放內(nèi)存),那么你得重載 ::operator delete(void*),讓它的行為與你的 operator new(size_t size, const char* file, int line) 匹配。一旦你決定重載 ::operator delete(void*),那么你必須重載 ::operator new(size_t),這就回到了情況 1:你無權(quán)重載全局 ::operator new(size_t)。
  • 如果選擇兼容系統(tǒng)默認(rèn)的 ::operator delete(void*),那么你在 operator new(size_t size, const char* file, int line) 里能做的事情非常有限,比方說你不能額外動態(tài)分配內(nèi)存來做 house keeping 或保存統(tǒng)計數(shù)據(jù)(無論顯示還是隱式),因為系統(tǒng)默認(rèn)的 ::operator delete(void*) 不會釋放你額外分配的內(nèi)存。(這里隱式分配內(nèi)存指的是往 std::map<> 這樣的容器里添加元素。)

看到這里估計很多人已經(jīng)暈了,但這還沒完。

其次,在 library 里重載 operator new(size_t size, const char* file, int line) 還涉及到你的重載要不要暴露給 library 的使用者(其他 library 或主程序)。這里“暴露”有兩層意思:1) 包含你的頭文件的代碼會不會用你重載的 ::operator new(),2) 重載之后的 ::operator new() 分配的內(nèi)存能不能在你的 library 之外被安全地釋放。如果不行,那么你是不是要暴露某個接口函數(shù)來讓使用者安全地釋放內(nèi)存?或者返回 shared_ptr ,利用其“捕獲”deleter 的特性?聽上去好像挺復(fù)雜?這里就不一一展開討論了,總之,作為 library 的作者,絕對不要動“重載 operator new()”的念頭。

事實 2:在主程序里重載 ::operator new() 作用不大

這不是一條規(guī)則,而是我試圖說明這么做沒有多大意義。

如果用第一種方式重載全局 ::operator new(size_t),會影響本程序用到的所有 C++ library,這么做或許不會有什么問題,不過我建議你使用下一節(jié)介紹的更簡單的“替代辦法”。

如果用第二種方式重載 ::operator new(size_t size, const char* file, int line),那么你的行為是否惠及本程序用到的其他 C++ library 呢?比方說你要不要統(tǒng)計 C++ library 中的內(nèi)存使用情況?如果某個 library 會返回它自己用 new 分配的內(nèi)存和對象,讓你用完之后自己釋放,那么是否打算對錯誤釋放內(nèi)存做檢查?

C++ library 從代碼組織上有兩種形式:1) 以頭文件方式提供(如以 STL 和 Boost 為代表的模板庫);2) 以頭文件+二進(jìn)制庫文件方式提供(大多數(shù)非模板庫以此方式發(fā)布)。

對于純以頭文件方式實現(xiàn)的 library,那么你可以在你的程序的每個 .cpp 文件的第一行包含重載 ::operator new 的頭文件,這樣程序里用到的其他 C++ library 也會轉(zhuǎn)而使用你的 ::operator new 來分配內(nèi)存。當(dāng)然這是一種相當(dāng)有侵略性的做法,如果運氣好,編譯和運行都沒問題;如果運氣差一點,可能會遇到編譯錯誤,這其實還不算壞事;運氣更差一點,編譯沒有錯誤,運行的時候時不時出現(xiàn)非法訪問,導(dǎo)致 segment fault;或者在某些情況下你定制的分配策略與 library 有沖突,內(nèi)存數(shù)據(jù)損壞,出現(xiàn)莫名其妙的行為。

對于以庫文件方式實現(xiàn)的 library,這么做并不能讓其受惠,因為 library 的源文件已經(jīng)編譯成了二進(jìn)制代碼,它不會調(diào)用你新重載的 ::operator new(想想看,已經(jīng)編譯的二進(jìn)制代碼怎么可能提供額外的 new (__FILE__, __LINE__) 參數(shù)呢?)更麻煩的是,如果某些頭文件有 inline function,還會引起詭異的“串?dāng)_”。即 library 有的部分用了你的分配器,有的部分用了系統(tǒng)默認(rèn)的分配器,然后在釋放內(nèi)存的時候沒有給對地方,造成分配器的數(shù)據(jù)結(jié)構(gòu)被破壞。

總之,第二種重載方式看似功能更豐富,但其實與程序里使用的其他 C++ library 很難無縫配合。

 

綜上,對于現(xiàn)實生活中的 C++ 項目,重載 ::operator new() 幾乎沒有用武之地,因為很難處理好與程序所用的 C++ library 的關(guān)系,畢竟大多數(shù) library 在設(shè)計的時候沒有考慮到你會重載 ::operator new() 并強塞給它。

如果確實需要定制內(nèi)存分配,該如何辦?

替代辦法

很簡單,替換 malloc。如果需要,直接從 malloc 層面入手,通過 LD_PRELOAD 來加載一個 .so,其中有 malloc/free 的替代實現(xiàn)(drop-in replacement),這樣能同時為 C 和 C++ 代碼服務(wù),而且避免 C++ 重載 ::operator new() 的陰暗角落。

對于“檢測內(nèi)存錯誤”這一用法,我們可以用 valgrind 或者 dmalloc 或者 efence 來達(dá)到相同的目的,專業(yè)的除錯工具比自己山寨一個內(nèi)存檢查器要靠譜。

對于“統(tǒng)計內(nèi)存使用數(shù)據(jù)”,替換 malloc 同樣能得到足夠的信息,因為我們可以用 backtrace() 函數(shù)來獲得調(diào)用棧,這比 new (__FILE__, __LINE__) 的信息更豐富。比方說你通過分析 (__FILE__, __LINE__) 發(fā)現(xiàn) std::string 大量分配釋放內(nèi)存,有超出預(yù)期的開銷,但是你卻不知道代碼里哪一部分在反復(fù)創(chuàng)建和銷毀 std::string 對象,因為 (__FILE__, __LINE__) 只能告訴你最內(nèi)層的調(diào)用函數(shù)。用 backtrace() 能找到真正的發(fā)起調(diào)用者。

對于“性能優(yōu)化”這一用法,我認(rèn)為這目前的多線程開發(fā)中,自己實現(xiàn)一個能打敗系統(tǒng)默認(rèn)的 malloc 的內(nèi)存分配器是不現(xiàn)實的。一個通用的內(nèi)存分配器本來就有相當(dāng)?shù)碾y度,為多線程程序?qū)崿F(xiàn)一個安全和高效的通用(全局)內(nèi)存分配器超出了一般開發(fā)人員的能力。不如使用現(xiàn)有的針對多核多線程優(yōu)化的 malloc,例如 Google tcmalloc 和 Intel TBB 2.2 里的內(nèi)存分配器。好在這些 allocator 都不是侵入式的,也無須重載 ::operator new()。

為單獨的 class 重載 operator new() 有問題嗎?

與全局 ::operator new() 不同,per-class operator new() 和 operator delete () 的影響面要小得多,它只影響本 class 及其派生類。似乎重載 member operator new() 是可行的。我對此持反對態(tài)度。

如果一個 class Node 需要重載 member operator new(),說明它用到了特殊的內(nèi)存分配策略,常見的情況是使用了內(nèi)存池或?qū)ο蟪?。我寧愿把這一事實明顯地擺出來,而不是改變 new Node 的默認(rèn)行為。具體地說,是用 factory 來創(chuàng)建對象,比如 static Node* Node::createNode() 或者 static shared_ptr<Node> Node::createNode();。

這可以歸結(jié)為最小驚訝原則:如果我在代碼里讀到 Node* p = new Node,我會認(rèn)為它在 heap 上分配了內(nèi)存,如果 Node class 重載了 member operator new(),那么我要事先仔細(xì)閱讀 node.h 才能發(fā)現(xiàn)其實這行代碼使用了私有的內(nèi)存池。為什么不寫得明確一點呢?寫成 Node* p = Node::createNode(),那么我能猜到 Node::createNode() 肯定做了什么與 new Node 不一樣的事情,免得將來大吃一驚。

The Zen of Python 說 explicit is better than implicit,我深信不疑。

 

總結(jié):重載 ::operator new() 或許在某些臨時的場合能應(yīng)個急,但是不應(yīng)該作為一種策略來使用。如果需要,我們可以從 malloc 層面入手,徹底而全面地替換內(nèi)存分配器。

參考文獻(xiàn):

[1] 侯捷,《池內(nèi)春秋—— Memory Pool 的設(shè)計哲學(xué)與無痛運用》,《程序員》2002 年第 9 期。

posted on 2011-02-22 01:02 陳碩 閱讀(20190) 評論(12)  編輯 收藏 引用

評論

# re: C++ 工程實踐(2):不要重載全局 ::operator new()[未登錄] 2011-02-22 07:10 欲三更

不同模塊的內(nèi)存問題,我覺得這簡直是一個c++設(shè)計欠考慮的地方。就算是不重載new也不見得沒問題。只要不是自己源碼編譯的模塊都不保險。  回復(fù)  更多評論   

# re: C++ 工程實踐(2):不要重載全局 ::operator new() 2011-02-22 10:00 空明流轉(zhuǎn)

allocator的作用很重要。  回復(fù)  更多評論   

# re: C++ 工程實踐(2):不要重載全局 ::operator new() 2011-02-22 13:41 陳梓瀚(vczh)

VC++內(nèi)置內(nèi)存跟蹤工具  回復(fù)  更多評論   

# re: C++ 工程實踐(2):不要重載全局 ::operator new() 2011-02-22 15:15 泛泛

不錯~~~~~~~~~~~~~~~~~~  回復(fù)  更多評論   

# re: C++ 工程實踐(2):不要重載全局 ::operator new()[未登錄] 2011-02-22 16:01 ccc

寫的很好  回復(fù)  更多評論   

# re: C++ 工程實踐(2):不要重載全局 ::operator new() 2011-02-22 17:02 zwp

受教了:)  回復(fù)  更多評論   

# re: C++ 工程實踐(2):不要重載全局 ::operator new()[未登錄] 2011-02-22 21:10 xxx

被同事的重載operator new害過的人路過。  回復(fù)  更多評論   

# Term Paper Writing Service 2011-03-12 13:52 Term Paper Writing Service

Writing Services to help students write essays, term papers, research papers. Buy custom research essay, custom term papers, thesis and dissertation writing.
  回復(fù)  更多評論   

# re: C++ 工程實踐(2):不要重載全局 ::operator new()[未登錄] 2011-12-22 14:09 Chipset

內(nèi)存管理系統(tǒng)的事情,對C++要求這么高,是不是太過分了。new就是一個殼,調(diào)了API。當(dāng)然,最好別重載全局new,局部的我看也最好別重載。一般程序new就足矣,多CPU并行和吞吐量的程序,只能自己來管內(nèi)存,否則慢也就罷了,還出一堆碎片。

系統(tǒng)管理內(nèi)存都做不到完美,指望語言級別依賴于實現(xiàn)的new能做好?看看系統(tǒng)內(nèi)核每次升級,有多少改動發(fā)生在虛擬內(nèi)存管理器...  回復(fù)  更多評論   

# re: C++ 工程實踐(2):不要重載全局 ::operator new() 2012-01-13 21:32 幻の上帝

不重載class scope operator new這種自我閹割的限制性手法居然成了符合最小驚訝?呵呵。我倒是挺愿意打那些既沒學(xué)好基本語義又懶得看清楚文檔的家伙們的臉的。
Explicit is better than implicit,雖然原意是沒什么錯,嘛,某些人就是擺脫不了用得羅嗦的原罪。要在這方面鼓吹這個是拉攏BASIC用戶么。
  回復(fù)  更多評論   

# re: C++ 工程實踐(2):不要重載全局 ::operator new() 2013-07-12 18:15 thomax

great content  回復(fù)  更多評論   

# re: C++ 工程實踐(2):不要重載全局 ::operator new() 2013-07-12 20:17 david parker

nice post  回復(fù)  更多評論   


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


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

導(dǎo)航

統(tǒ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>
            国产精品v欧美精品∨日韩| 欧美一区二区黄色| 欧美激情精品久久久久| 久久久久这里只有精品| 在线观看亚洲精品视频| 亚洲福利电影| 欧美精品性视频| 亚洲影院色在线观看免费| 亚洲综合导航| 亚洲国产另类久久久精品极度| 猛男gaygay欧美视频| 欧美成人午夜激情视频| 亚洲一级黄色| 久久精品一级爱片| 亚洲精品永久免费| 中文在线资源观看网站视频免费不卡 | 欧美一区高清| 亚洲黄色尤物视频| 亚洲一本视频| 亚洲欧洲一区| 亚洲欧美综合v| 国产精品国色综合久久| 欧美一区二区三区男人的天堂| 久久久久高清| 亚洲一区二区三区乱码aⅴ| 久久av最新网址| 在线午夜精品| 久久蜜臀精品av| 性感少妇一区| 欧美久久久久久久久| 久久米奇亚洲| 国产精品卡一卡二| 亚洲国产天堂久久综合| 国产婷婷97碰碰久久人人蜜臀| 亚洲国产成人久久综合一区| 国产亚洲精品美女| 一本色道久久88亚洲综合88 | 久久久午夜精品| 亚洲欧美日韩人成在线播放| 欧美岛国在线观看| 久久一日本道色综合久久| 欧美日韩在线亚洲一区蜜芽| 欧美激情在线| 狠狠狠色丁香婷婷综合激情| 亚洲自拍偷拍福利| 亚洲午夜久久久久久久久电影院| 老司机成人网| 蜜臀av国产精品久久久久| 国产欧美69| 亚洲一区二区三区久久| 日韩一区二区免费高清| 久久精品99国产精品日本| 小辣椒精品导航| 国产精品白丝jk黑袜喷水| 91久久久久久久久| 91久久精品国产91性色tv| 久久av一区二区三区漫画| 欧美亚洲综合久久| 国产精品久久久久久久久久久久久久 | 一区二区三区视频在线观看| 老牛影视一区二区三区| 女女同性精品视频| 伊人久久噜噜噜躁狠狠躁| 欧美一区视频在线| 久久福利毛片| 黄色成人91| 久久久99久久精品女同性| 久久伊人亚洲| 一区在线播放| 另类酷文…触手系列精品集v1小说| 久久久亚洲一区| 伊人精品在线| 欧美mv日韩mv国产网站app| 欧美激情在线狂野欧美精品| 亚洲精品一区二区三| 欧美久久久久久久久| 一本色道久久综合亚洲二区三区| 亚洲一线二线三线久久久| 国产精品久久久久久影视| 亚洲欧美日韩一区二区在线 | 午夜精品一区二区三区在线| 亚洲专区免费| 国产精品二区影院| 亚洲欧美日韩精品| 免费一区视频| 在线亚洲欧美专区二区| 国产精品入口日韩视频大尺度 | 久久香蕉国产线看观看av| 亚洲第一搞黄网站| 欧美日韩午夜在线| 欧美一区日本一区韩国一区| 欧美国产日韩一区二区| 亚洲综合久久久久| 在线观看视频一区二区欧美日韩| 欧美精品一区二区视频| 亚洲欧美在线一区二区| 欧美风情在线观看| 亚洲欧美一区二区原创| 影音先锋中文字幕一区| 国产亚洲综合性久久久影院| 亚洲一区www| 欧美国产免费| 亚洲综合首页| 亚洲黑丝在线| 国产日韩欧美在线播放不卡| 欧美成人影音| 性欧美1819sex性高清| 91久久夜色精品国产网站| 久久精品国产99| 亚洲性视频h| 亚洲国产精品悠悠久久琪琪| 国产精品欧美风情| 欧美精品三级在线观看| 久久久噜噜噜久噜久久| 亚洲视频在线观看视频| 亚洲激情女人| 你懂的国产精品| 欧美在线视频在线播放完整版免费观看| 激情五月***国产精品| 国产精品高精视频免费| 久久午夜精品一区二区| 欧美亚洲在线播放| 中文亚洲字幕| 亚洲每日更新| 最新中文字幕亚洲| 欧美 日韩 国产 一区| 亚洲女性裸体视频| 一区二区三区日韩欧美精品| 91久久精品国产91久久| 精久久久久久| 狠狠色综合一区二区| 国产嫩草一区二区三区在线观看| 欧美日韩一区视频| 欧美日韩国产三级| 欧美激情视频网站| 欧美精品在线观看| 欧美福利网址| 欧美日韩国产精品一卡| 欧美高清在线视频| 欧美国产精品专区| 欧美日韩ab| 欧美日产国产成人免费图片| 欧美国产日韩免费| 免费在线成人| 欧美激情精品久久久久久免费印度 | 久久最新视频| 性久久久久久久久久久久| 一本色道久久综合亚洲精品不卡| 亚洲美女视频在线观看| 亚洲精品久久久久久久久| 亚洲福利专区| 欧美高清成人| 亚洲最新色图| 亚洲网站在线观看| 亚洲一区二区在线看| 亚洲欧美激情视频在线观看一区二区三区| 日韩视频不卡| 午夜精品久久久久久久久久久| 亚洲欧美一区二区激情| 久久久999精品视频| 裸体歌舞表演一区二区| 农夫在线精品视频免费观看| 欧美日本韩国一区二区三区| 国产精品分类| 国内欧美视频一区二区| 亚洲人成在线影院| 亚洲一区二区三区免费视频| 欧美中文在线观看国产| 免费观看亚洲视频大全| 亚洲日本va在线观看| 亚洲午夜一区| 久久久久久亚洲综合影院红桃| 久久尤物电影视频在线观看| 欧美区国产区| 国产九九视频一区二区三区| 激情小说另类小说亚洲欧美| 99re热精品| 久久亚裔精品欧美| 日韩午夜av| 久久精品日产第一区二区三区| 欧美风情在线观看| 国产欧美大片| 夜夜嗨av色一区二区不卡| 亚洲欧美国产另类| 亚洲国产精品成人va在线观看| 亚洲免费视频观看| 欧美成人dvd在线视频| 国产日韩精品在线| 日韩亚洲不卡在线| 老巨人导航500精品| 亚洲高清不卡av| 欧美在线不卡视频| 国产精品美女一区二区在线观看| 亚洲国产综合91精品麻豆| 亚洲欧美日韩一区| 亚洲美洲欧洲综合国产一区| 久久人体大胆视频| 久久伊人精品天天| 中文av字幕一区| 亚洲国产欧美久久|