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

陳碩的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>
            蜜桃视频一区| 国产一区观看| 性久久久久久久| 午夜精品一区二区三区电影天堂 | 亚洲国产精品激情在线观看| 久久精品二区| 美女啪啪无遮挡免费久久网站| 另类酷文…触手系列精品集v1小说| 欧美.日韩.国产.一区.二区| 亚洲国产一区二区a毛片| 日韩视频永久免费| 亚洲欧美另类在线| 免费不卡中文字幕视频| 欧美日韩免费一区二区三区| 国产精品一级在线| 亚洲国产成人一区| 亚洲视屏一区| 久热这里只精品99re8久| 最新高清无码专区| 性久久久久久久久| 欧美日韩国产不卡在线看| 国产视频观看一区| 亚洲乱码国产乱码精品精可以看| 亚洲欧美国产制服动漫| 蜜桃久久av一区| 夜夜嗨一区二区| 久久久噜噜噜久久中文字免| 欧美日韩一区二区三区免费看| 国产三级精品三级| 亚洲天堂男人| 亚洲成色最大综合在线| 午夜精品网站| 国产精品乱码人人做人人爱| 亚洲精品小视频| 久久中文欧美| 新狼窝色av性久久久久久| 欧美日韩大片| 亚洲精品1区| 免费av成人在线| 亚洲欧美综合国产精品一区| 欧美喷潮久久久xxxxx| 亚洲大片免费看| 久久久久久久精| 亚洲欧美一区二区三区在线| 欧美日韩国产一区二区| 在线视频成人| 久久亚洲精选| 久久久久九九视频| 国产一区亚洲一区| 久久精品国产清高在天天线| 亚洲欧美日韩另类精品一区二区三区| 欧美日韩国产免费| 99re6这里只有精品| 亚洲二区在线视频| 久久精品国产精品| 欧美一级欧美一级在线播放| 国产精品一区二区三区成人| 午夜激情综合网| 亚洲欧美国产三级| 国产亚洲欧美一区在线观看| 亚洲欧美中文在线视频| 中文亚洲欧美| 国产精品久久久久三级| 亚洲欧美日韩天堂| 亚洲欧美中文字幕| 国产在线高清精品| 模特精品裸拍一区| 欧美国产先锋| 亚洲网站啪啪| 亚洲小说欧美另类婷婷| 国产精品视区| 久久在线免费| 欧美激情精品久久久六区热门 | 日韩一级欧洲| 国产精品毛片va一区二区三区| 亚洲一区免费在线观看| 亚洲一区国产一区| 狠狠噜噜久久| 亚洲成色777777在线观看影院| 欧美精品一区三区| 亚洲欧美另类在线| 久久久国产亚洲精品| 亚洲精品乱码| 亚洲男人天堂2024| 亚洲国产日韩欧美在线图片| 亚洲日本在线视频观看| 国产亚洲福利| 91久久久精品| 国产日本欧美一区二区三区| 蜜臀a∨国产成人精品| 欧美日韩国产精品一区| 久久久青草婷婷精品综合日韩| 久久综合伊人77777蜜臀| 亚洲永久免费观看| 久久网站热最新地址| 亚洲视频在线观看免费| 久久久一本精品99久久精品66| 夜夜嗨av一区二区三区免费区| 亚洲欧美综合| 亚洲视频一区在线观看| 久久久天天操| 午夜视黄欧洲亚洲| 欧美电影资源| 久久一区二区三区av| 国产精品v片在线观看不卡| 免费在线观看日韩欧美| 国产精品中文字幕欧美| 亚洲精品1234| 在线成人黄色| 亚洲主播在线| 亚洲综合国产精品| 欧美激情亚洲| 91久久午夜| 久久久99爱| 久久成人国产精品| 国产精品你懂的| 亚洲美女中文字幕| 日韩小视频在线观看专区| 久久在线免费观看视频| 久久激情综合网| 国产精品乱码人人做人人爱| 亚洲精品一区二区三区樱花 | 欧美午夜免费影院| 亚洲国产一成人久久精品| 在线日韩欧美| 猛男gaygay欧美视频| 免费中文日韩| 亚洲精品1区2区| 久久久www免费人成黑人精品| 欧美中日韩免费视频| 国产精品久久久久久久7电影| 亚洲人人精品| 日韩视频在线观看一区二区| 欧美va日韩va| 亚洲欧洲在线一区| 一本久久a久久精品亚洲| 欧美精品一区在线发布| 99爱精品视频| 欧美一区二区三区免费大片| 国产精品尤物福利片在线观看| 一区二区三区久久久| 亚洲综合国产| 国产一区二区观看| 久久久久久一区二区三区| 毛片一区二区三区| 亚洲激情视频| 欧美日韩精品免费在线观看视频| 亚洲精品网址在线观看| 夜夜爽夜夜爽精品视频| 国产精品久久久久91| 香蕉av777xxx色综合一区| 久久三级视频| 亚洲精品日韩久久| 国产精品成人一区二区艾草| 亚洲免费网站| 欧美国产视频日韩| 亚洲神马久久| 国产午夜亚洲精品不卡| 久久综合久久综合久久综合| 最新日韩精品| 午夜精品福利在线| 韩国三级在线一区| 欧美日韩成人综合在线一区二区| 亚洲一区在线免费观看| 久久亚洲综合色| 99国产精品99久久久久久| 国产精品午夜久久| 久久久久久一区二区三区| 99pao成人国产永久免费视频| 欧美一区二区网站| 亚洲精选大片| 狠狠色丁香久久婷婷综合丁香| 欧美激情国产日韩精品一区18| 国产精品99久久久久久久vr| 久久综合网hezyo| 亚洲一区二区欧美日韩| 狠色狠色综合久久| 国产精品白丝jk黑袜喷水| 久久精品一区二区三区中文字幕| 日韩亚洲成人av在线| 久久色在线播放| 午夜精品久久久久久久| 欧美网站在线| 久久久久久久欧美精品| 亚洲视频在线观看网站| 欧美福利一区二区三区| 亚洲摸下面视频| 亚洲精选大片| 亚洲国产精品成人一区二区 | 亚洲一区二区三区精品动漫| 欧美成人官网二区| 久久狠狠婷婷| 亚洲永久字幕| 99精品福利视频| 最新国产乱人伦偷精品免费网站| 国产日韩欧美综合| 国产精品一区二区久久久久| 欧美日韩一区二区视频在线观看| 久久免费视频在线观看| 欧美一区二区三区四区在线|