看到這個題目，可能有些人會覺得奇怪——Object不是JS的基本數據類型么，有什么實現不實現的呢？如果你這么想的話，說明你沒有接觸過其它語言，一直都是在和JS打交道，編程世界那么大，你沒有出去看一看。C/C++/Java等語言是沒有這種json的數據類型的，其它一些有的：如在Pthyon里面叫做字典，在Ruby/Perl里面叫散列表，當然這只是個名稱而已，本質上可以當作json類型。而C是“萬物之母”，C里面沒有的，就得通過某種方式實現。
並且JS里面的Object是如何查找屬性的，這個問題有人說是通過遍歷key的字符串查找的，也有人說是通過哈希查找的。究竟它是怎么存儲和查找的，能不能把Object當作一個map來使用？如果無法從源碼的角度實際地看一下瀏覽器的實現，你的觀點可能就站不住腳，只能人雲亦雲。
Chrome自行開發了V8引擎，並被Node拿去當解析器。本文將通過V8的源碼嘗試分析Object的實現。
1. V8的代碼結構
v8的源碼位於src/v8/src/，代碼層級相對比較簡單，但是實現比較復雜，為了能看懂，需要找到一個切入點，通過打斷點、加log等方式確定這個切入點是對的，如果這個點並不是關鍵的點，進行到某一步的時候就斷了，那么由這個點出發嘗試去找其它的點。不斷驗證，最后找到一個最關鍵的地方，由這個地方由淺入深地擴展到其它地方，最后形成一個體系。
以下，先說明JS Object的類圖。
2. JS Object類圖
V8里面所有的數據類型的根父類都是Object，Object派生HeapObject，提供存儲基本功能，往下的JSReceiver用於原型查找，再往下的JSObject就是JS里面的Object，Array/Function/Date等繼承於JSObject。左邊的FixedArray是實際存儲數據的地方。
3. 創建JSObject
在創建一個JSObject之前，會先把讀到的Object的文本屬性序列化成constant_properties，如下的data：
var data = { name: "yin", age: 18, "-school-": "high school" }; 會被序列成：
../../v8/src/runtime/http://runtime-literals.cc 72 constant_properties:
0xdf9ed2aed19: [FixedArray]
– length: 6
[0]: 0x1b5ec69833d1 <String[4]: name>
[1]: 0xdf9ed2aec51 <String[3]: yin>
[2]: 0xdf9ed2aec71 <String[3]: age>
[3]: 18
[4]: 0xdf9ed2aec91 <String[8]: -school->
[5]: 0xdf9ed2aecb1 <String[11]: high school>
它是一個FixedArray，一共有6個元素，由於data總共是有3個屬性，每個屬性有一個key和一個value，所以Array就有6個。第一個元素是第一個key，第二個元素是第一個value，第三個元素是第二個key，第四個元素是第二個key，依次類推。Object提供了一個Print()的函數，把它用來打印對象的信息非常有幫助。上面的輸出有兩種類型的數據，一種是String類型，第二種是整型類型的。
FixedArray是V8實現的一個類似於數組的類，它表示一段連續的內存，上面的FixedArray的length = 6，那么它占的內存大小將是：
length * kPointerSize
因為它存的都是對象的指針（或者直接是整型數據類型，如上面的18），在64位的操作系統上，一個指針為8個字節，它的大小將是48個字節。它記錄了一個初始的內存開始地址，使用元素index乘以指針大小作為偏移，加上開始地址，就可以取到相應index的元素，這和數組是一樣的道理。只是V8自己封裝了一個，方便添加一些自定義的函數。
FixedArray主要用於表示數據的存儲位置，在它上面還有一個Map，這個Map用於表示數據的結構。這里的Map並不是哈希的意思，更接近於地圖的意義，用來操作FixedArray表示的這段內存。V8根據constant_properties的length，去開辟相應大小空間的Map：
Handle<Map> map = ComputeObjectLiteralMap(context, constant_properties, &is_result_from_cache); 把這個申請后的Map打印出來：
../../v8/src/heap/http://heap.cc 3472 map is
0x21528af9cb39: [Map]
– type: JS_OBJECT_TYPE
– instance size: 48
– inobject properties: 3
– back pointer: 0x3e2ca8902311 <undefined>
– instance descriptors (own) #0: 0x3e2ca8902231 <FixedArray[0]>
從第4行加粗字體可以看到，它的大小確實和我們算的一樣。並且它還有一個叫做descriptors表示它的數據結構。descriptor記錄了每個key-value對，以及它們在FixedArray里面的index. 后續對properties的操作基本上通過descriptor進行。
有了這個map的對象之后，用它來創建一個JSObect：
Handle<JSObject> boilerplate = isolate->factory()->NewJSObjectFromMap(map, pretenure_flag); 重新開辟一段內存，把map的內容拷過去。
由於map只是一段相應大小的內存空間，它的內容是空的，所以接下來要設置它的properties：
for (int index = 0; index < length; index += 2) { Handle<Object> key(constant_properties->get(index + 0)); Handle<Object> value(constant_properties->get(index + 1)); Handle<String> name = Handle<String>::cast(key); JSObject::SetOwnPropertyIgnoreAttributes(boilerplate, name, value, NONE); } 通過上面的代碼，把properties設置到map的FixedArray里面，並且可以通過index用descriptors迅速地取出key-value。由於這個過程比較復雜，細節不展開討論。
在設置properties的同時，會初始化一個searchCache，這個cache支持哈希查找某個屬性。
4. 字符串哈希查找
在設置cache的時候，會先進行查找是否已存在相同的屬性名，如果已經有了就把它的value值覆蓋掉，否則把它添加到cache里面：
int DescriptorArray::SearchWithCache(Isolate* isolate, Name* name, Map* map) { DescriptorLookupCache* cache = isolate->descriptor_lookup_cache(); //找到它的index int number = cache->Lookup(map, name); //如果沒有的話 if (number == DescriptorLookupCache::kAbsent) { //通過遍歷找到它的index number = Search(name, number_of_own_descriptors); //更新cache cache->Update(map, name, number); } return number; } 如上代碼的注釋，我們先來看一下這個Search函數是怎么進行的：
template <SearchMode search_mode, typename T> int Search(T* array, Name* name, int valid_entries, int* out_insertion_index) { // Fast case: do linear search for small arrays. const int kMaxElementsForLinearSearch = 8; if (valid_entries <= kMaxElementsForLinearSearch) { return LinearSearch<search_mode>(array, name, valid_entries, out_insertion_index); } // Slow case: perform binary search. return BinarySearch<search_mode>(array, name, valid_entries, out_insertion_index); } 如果屬性少於等於8個時，則直接線性查找即依次遍歷，否則進行二分查找，在線性查找里面判斷是否相等，是用的內存地址比較：
for (int number = 0; number < valid_entries; number++) { if (array->GetKey(number) == name) return number; } 因為name都是用的上面第三點設置Map的時候傳進來的name，因此初始化的時候相同的name都指向同一個對象。所以可以直接用內存地址進行比較，得到FixedArray的索引number。然后用key和number去update cache：
cache->Update(map, name, number);
重點在於這個update cache。這個cache的數據結構是這樣的：
static const int kLength = 64;
struct Key {
Map* source;
Name* name;
};
Key keys_[kLength];
int results_[kLength];
它有一個數組keys_的成員變量存放key，這個數組的大小是64，數組的索引用哈希算出來，不同的key有不同的哈希，這個哈希就是它在數組里面的索引。它還有一個results_，存放上面線性查找出來的number，這個number就是內存里面的偏移，有了這個偏移就可以很快地定位到它的內容，所以放到results里面.
關鍵在於這個哈希是怎么算的。來看一下update的函數：
void DescriptorLookupCache::Update(Map* source, Name* name, int result) { int index = Hash(source, name); Key& key = keys_[index]; key.source = source; key.name = name; results_[index] = result; } 先計算哈希索引index，然后把數據存到results_和keys_這兩個數組的index位置。這個Hash函數是這樣的：
int DescriptorLookupCache::Hash(Object* source, Name* name) { // Uses only lower 32 bits if pointers are larger. uint32_t source_hash = static_cast<uint32_t>(reinterpret_cast<uintptr_t>(source)) >> kPointerSizeLog2; uint32_t name_hash = name->hash_field(); return (source_hash ^ name_hash) % kLength; } 先計算map和key的hash，map的hash即source_hash是用map的地址的低32位，為了統一不同指針大小的區別，而計算key的hash即name_hash，最核心的代碼應該是以下幾行：
uint32_t StringHasher::AddCharacterCore(uint32_t running_hash, uint16_t c) { running_hash += c; running_hash += (running_hash << 10); running_hash ^= (running_hash >> 6); return running_hash; } 依次循環name的每個字符串做一些位運算，結果累計給running_hash.
source_hash是用map的內存地址，因為這個地址是唯一的，而name_hash是用的字符串的內容，只要字符串一樣，那么它的hash值就一定一樣，這樣保證了同一個object，它的同個key值的索引值就一定一樣。source_hash和name_hash最后異或一下，模以kLength = 64得到它在數組里面的索引。
這里自然而然會有一個問題，通過這樣的計算不能夠保證不同的name計算出來的哈希值一定不一樣，好的哈希算法只能讓結果盡可能隨機，但是無法做到一定不重復，所以這里也有同樣的問題。
先來看一下，它是怎么查找的：
int DescriptorLookupCache::Lookup(Map* source, Name* name) { int index = Hash(source, name); Key& key = keys_[index]; if ((key.source == source) && (key.name == name)) return results_[index]; return kAbsent; } 先用同樣的哈希算法，算出同樣的index，取出key里面的map和name，和存儲的map和name進行比較，如果相同則說明找到了，否則的話返回不存在-1的標志。一旦不存在了又會執行上面的update cache，先調Search找到它的偏移index作為result，如果index存在重新update cache。所以上面的問題就可以得到解答了，重復的哈希索引覆蓋了第一個，導致查找第一個的時候沒找找到，所以又去重新update，把那個索引值的數組元素又改成了第一個的。因此，如果兩個重復的元素如果循環輪流訪問的話，就會造成不斷地查找index，不斷地更新搜索cache。但是這種情況還是比較少的。
如何保證傳進來的具有相同字符串的name和原始的name是同一個對象，從而才能使它們的內存地址一樣？一個辦法是維護一個Name的數據池，據有相同字符串的name只能存在一個。
上面的那個data它的三個name的index在筆者電腦上實驗計算結果為：
#name hash index = 62
#age hash index = 32
#-school- hash index = 51
有一個比較奇怪的地方是重復實驗，它們的哈希值都是一樣的。並且具有相同屬性且順序也相同的object，它們的map地址就是一樣的。
如果一個元素的屬性值超過64個呢？那也是同樣的處理，后面設置的會覆蓋前面設置的。學過哈希的都知道，當元素的個數大於容器容量的一半時，重復的概率將會大大增加。所以一個object的屬性的比較優的最大大小為32。一旦超過32，在一個：
for(var key in obj){ obj[key] //do sth. } for循環里面，這種查找的開銷將會很大。但是考慮到屬性個數並不多。
那為什么它要把長度設置成64呢，如果改大了，不就可以減少重復率？但是這樣會造成更多的內存消耗，即使一個Object只有一個屬性，它也會初始化一個這么大的數組，對於這種屬性比較少的object來說就很浪費。所以取64，應該是一個比較適中的值。
同時另一方面，經常使用的那幾個屬性還是能夠很快通過哈希計算定位到它的內容。並且這種場景還是很常見的，如獲取數組元素的lengh.
這種cache查找只支持屬性個數小於等於128的，如果屬性個數大於128個，將不采用cache存儲和查找的方式。而是直接使用一個hashtable
5. 字符串哈希表查找
如下的判斷：
const int kMapCacheSize = 128;
// We do not cache maps for too many properties or when running builtin code.
if (number_of_properties > kMapCacheSize) {
*is_result_from_cache = false;
Handle<Map> map = Map::Create(isolate(), number_of_properties);
return map;
}
如果屬性個數大於128時，將按照屬性的個數消耗的空間創建和擴展map存儲，不再創建cache。同時這個map就會被標記為dictionary_map，即哈希表。
往這個哈希表插入一個元素前，會先檢查表的容量是否足夠，不夠進行擴容，在EnsureCapacity的函數里面：
int capacity = table->Capacity();
int nof = table->NumberOfElements() + n;
if (table->HasSufficientCapacityToAdd(n)) return table;
Handle<Derived> new_table = HashTable::New(
nof * 2,
USE_DEFAULT_MINIMUM_CAPACITY);
table->Rehash(new_table, key);
第二行獲取到當前表元素個數加上需要插入的元素的個數得到新表的總元素個數；第7行再乘以2，得到新表的容量，最后再rehash，重新計算每個元素的哈希值，更新哈希表。
插入一個元素的關鍵是計算它的哈希，這里計算哈希的方式和上面的一樣，都是調的name->hash_field函數，不一樣的是它不再是覆蓋存儲，因為上面已經進行擴容了，可以保證空間一定足夠。如果哈希值沖突了，那么將一直找到下一個存放它的地方，如下面的FindInsertionEntry函數：
template<typename Derived, typename Shape, typename Key> uint32_t HashTable<Derived, Shape, Key>::FindInsertionEntry(uint32_t hash) { uint32_t capacity = Capacity(); uint32_t entry = FirstProbe(hash, capacity); uint32_t count = 1; // EnsureCapacity will guarantee the hash table is never full. Isolate* isolate = GetIsolate(); while (true) { Object* element = KeyAt(entry); if (!IsKey(isolate, element)) break; entry = NextProbe(entry, count++, capacity); } return entry; } 在上面代碼第10行找到一個非key元素后，停止循環，返回這個位置。
在所有屬性插入完成之后，查找的過程類似於上面的插入，如下面FindEntry的函數：
// Find entry for key otherwise return kNotFound.
template <typename Derived, typename Shape>
int NameDictionaryBase<Derived, Shape>::FindEntry(Handle<Name> key) {
// EnsureCapacity will guarantee the hash table is never full.
uint32_t capacity = this->Capacity();
uint32_t entry = Derived::FirstProbe(key->Hash(), capacity);
uint32_t count = 1;
while (true) {
Object* element = this->KeyAt(entry);
if (element->IsUndefined(isolate)) break; // Empty entry.
if (*key == element) return entry;
entry = Derived::NextProbe(entry, count++, capacity);
}
return Derived::kNotFound;
}
在while循環里，要么找到一個undefined的元素，返回無結果的標志，要么命中元素，返回FixedArray的索引index，然后通過這個數組index就可以很快地取出數據：
property_details_ = dictionary->DetailsAt(entry);
當哈希值沖突時，如何找到下一個插入位置，在哈希算法里面也是一個很重要的部分，因為需要定位到下一個空的元素，才能進行插入，如果定位到的下一個元素又是非空的，又得繼續找下一個。源碼里面是這樣進行的：
inline static uint32_t FirstProbe(uint32_t hash, uint32_t size) { return hash & (size - 1); } inline static uint32_t NextProbe( uint32_t last, uint32_t number, uint32_t size) { return (last + number) & (size - 1); }
所以當屬性個數不超過128個時，是用searchCache，大於128時，采用哈希表。源碼里面查找的判斷是這樣的：
if (!map->is_dictionary_map()) { DescriptorArray* descriptors = map->instance_descriptors(); int number = descriptors->SearchWithCache(isolate_, *name_, map); //... } else { NameDictionary* dict = holder->property_dictionary(); int number = dict->FindEntry(name_); //... } 如果是一個字典，則執行else里面的邏輯，否則執行if里面的邏輯按searchCache查找。
這里自然而然會有一個問題，為什么在不大於128個屬性的時候要專門搞一個searchCache呢，是因為searchCache比哈希表快么，快在哪里？我想這兩者的區別在於searchCache不會沖突，每次都是直接定位，而hashTable如果沖突了需要不斷地找下一個元素，增加了比較次數。當屬性比較少，並且有幾個屬性經常被用到的時候，searchCache應該會有明顯的優勢。
上面已經介紹了兩種字符串的查找方式，當屬性是數字的時候有另外兩種查找方式。
6. 數字索引哈希查找
假設data變成：
var data = { name: "yin", age: 18, "-school-": "high school", 1: "Monday", 2: "Thuesday", "3": "Wednesday" }; 把生成的data Object打印出來是這樣的：
../../v8/src/runtime/http://runtime-literals.cc 105 boilerplate obj:
0x3930221af3a9: [JS_OBJECT_TYPE]
- map = 0x6712e19cc41 [FastProperties]
- prototype = 0x27d71d20f19
- elements = 0x2e1e1a56b579 <FixedArray[19]> [FAST_HOLEY_ELEMENTS]
- properties = 0x2c2a4d782241 <FixedArray[0]> {
#name: 0x3930221aec51 <String[3]: yin> (data field at offset 0)
#age: 18 (data field at offset 1)
#-school-: 0x3930221aecb1 <String[11]: high school> (data field at offset 2)
}
- elements = {
0: 0x2c2a4d782351 <the hole>
1: 0x3930221aecf9 <String[6]: Monday>
2: 0x3930221aed39 <String[8]: Thuesday>
3: 0x3930221aed79 <String[9]: Wednesday>
4-18: 0x2c2a4d782351 <the hole>
}
那些key為數字的存放在elements的數據結構里面。上面的elements它是一個有序數組，它的key值直接作為它的index。如果data改成：
var data = { 1: "Monday", 2: "Thuesday", 3: "Wednesday", 7: "Sunday" } 那么elements是這樣的：
- elements = {
0: 0x1e74f5702351 <the hole>
1: 0x1745ec52ec71 <String[6]: Monday>
2: 0x1745ec52ecb1 <String[8]: Thuesday>
3: 0x1745ec52ecf1 <String[9]: Wednesday>
4-6: 0x1e74f5702351 <the hole>
7: 0x1745ec52ed39 <String[6]: Sunday>
8-18: 0x1e74f5702351 <the hole>
}
初始化大小仍然是19個元素，空的索引用hole元素填充。這種就跟數組一樣，可直接根據索引定位到元素，代價是空間的消耗比較大，可以來看一下，當空間不足時，它是怎么擴容的：
if (index < capacity) { *new_capacity = capacity; return false; } *new_capacity = JSObject::NewElementsCapacity(index + 1); 由於第一個屬性是1: Monday，所以上面的index = 1，執行最后一行計算新容量的元素：
// Computes the new capacity when expanding the elements of a JSObject. static uint32_t NewElementsCapacity(uint32_t old_capacity) { // (old_capacity + 50%) + 16 return old_capacity + (old_capacity >> 1) + 16; } 可以看到，這是用老的空間的一半加上16，上面的計算結果為19，如果本來是2M大小，剛好不夠再增加一個元素就成了3M，一個多余的元素就增加了1M的空間。它的好處是不用頻繁地開避內存。
這種用數組表示的屬性在源碼里面叫FastElements，而用哈希表的叫做SlowElements。什么時候會變成slowElements？當hole太多的時候，例如給data增加一個key為2000的屬性：
data['2000'] = 'day'; data就會轉成慢元素，因為3之后就是2000，hole太多就被轉換了，如下面的ShouldConvertToSlowElements函數：
static bool ShouldConvertToSlowElements(JSObject* object, uint32_t capacity, uint32_t index, uint32_t* new_capacity) { if (index < capacity) { return false; } //JSObject::kMaxGap = 1024 if (index - capacity >= JSObject::kMaxGap) return true; *new_capacity = JSObject::NewElementsCapacity(index + 1); // If the fast-case backing storage takes up roughly three times as // much space (in machine words) as a dictionary backing storage // would, the object should have slow elements. int used_elements = object->GetFastElementsUsage(); int dictionary_size = SeededNumberDictionary::ComputeCapacity(used_elements) * SeededNumberDictionary::kEntrySize; return 3 * static_cast<uint32_t>(dictionary_size) <= *new_capacity; } 如果當前的index比容量capacity大了1024，就轉成慢元素，或者是如上面的代碼注釋，如果快元素占的空間為慢元素的3倍之多時，也會被轉成慢元素。
轉成慢元素之后，它就和字符串的哈希表一樣了，不一樣的是，它計算哈希的方式不一樣，字符串的需要一個個字符串循環計算計算hash，而數字的key，不需要循環，如下計算（第二個參數是隨機化種子seed）：
inline uint32_t ComputeIntegerHash(uint32_t key, uint32_t seed) { uint32_t hash = key; hash = hash ^ seed; hash = ~hash + (hash << 15); // hash = (hash << 15) - hash - 1; hash = hash ^ (hash >> 12); hash = hash + (hash << 2); hash = hash ^ (hash >> 4); hash = hash * 2057; // hash = (hash + (hash << 3)) + (hash << 11); hash = hash ^ (hash >> 16); return hash & 0x3fffffff; }
然后再來簡單看一下ES6的Map的實現
7. ES6 Map的實現
這里有一個比較有趣的事情，就是V8的Map的核心邏輯是用JS實現的，具體文件是在v8/src/js/collection.js，用JS來實現JS，比寫C++要高效多了，但是執行效率可能就沒有直接寫C++的高，可以來看一下set函數的實現：
function MapSet(key, value) { //添加一個log %LOG("MapSet", key); var table = %_JSCollectionGetTable(this); var numBuckets = ORDERED_HASH_TABLE_BUCKET_COUNT(table); var hash = GetHash(key); var entry = MapFindEntry(table, numBuckets, key, hash); if (entry !== NOT_FOUND) return ...//return代碼省略 //如果個數大於capacity的二分之一，則執行%MapGrow(this)代碼略 FIXED_ARRAY_SET(table, index, key); FIXED_ARRAY_SET(table, index + 1, value); } 第三行添加一個log函數，確認確實是執行這里的代碼。%開頭的LOG，表示它是一個C++的函數，這個代碼寫在runtime.h和http://runtime.cc里面。這些JS代碼最后會被組裝成native code。在V8里，除了Map/Set之外，很多ES6新加的功能，都是用的JS實現的，如數組新加的很多函數。
8. Object和ES 6 Map的速度比較
Object和ES 6的map主要都是用的哈希，那么它們運行效率比較起來怎么樣呢？
如以下代碼，初始化一個map和一個object：
var map = new Map(), obj = {}; var size = 100000； for(var i = 0; i < size; i++){ map.set('key' + i , i); obj['key' + i] = i; } 再准備一個keys數組，用來存儲查找的key，如下，分成三種情況分別測驗：1. keys都能查到；2. 只有一半的keys能找到；3. 全部的keys都查找不到：
var keys = []; for(var i = 0; i < 100; i++){ //1. keys都找得到 keys.push('key' + parseInt(Math.random() * size)); //2. 約一半的keys找不到 //keys.push('key' + parseInt(Math.random() * size * 2)); //3. 全部的keys都找不到 //keys.push('key' + parseInt(Math.random() * size) + size); } 然后進行查找，重復多次，並打印時間：
var count = 100000; console.time("map time"); for(var i = 0; i < count; i++){ for(var j = 0; j < keys.length; j++){ let x = map.get(keys[j]); } } console.timeEnd("map time"); console.time("obj time"); for(var i = 0; i < count; i++){ for(var j = 0; j < keys.length; j++){ let x = obj[keys[j]]; } } console.timeEnd("obj time"); 最后的結果如下：
可以看到，當查找的keys找不到時，object更加地消耗時間（在實際的使用中，一半找得到一半找不到的情況應該會比較多一點）。這很可能是因為object里面每個key需要實例化一個全局唯一的name，如果name已經存在了，那么它已經實例化好了，包括它的哈希值計算已經緩存起來了，如果未知的name越多，那么需要實例化的name也就越多，而map不存在這種情況，每次都是重新計算哈希。另一方面還可能和它們的哈希算法有關。
綜上，Object存儲和查找一個屬性時，可通過以下方式：
屬性不超過128個，使用Search Cache，當屬性是較為連續的數字時，使用數組，此種方式最快。其它情況使用哈希表，並且數字和字符串的哈希不一樣。
可以把Object當成哈希map使用，但是在效率上可能會比不上ES6的Map，並且還有Object原型查找的問題。