查詢優化演算法

㈠ postgresql 查詢優化是選擇動態規劃演算法還是遺傳演算法

不是。遺傳演算法可以用於蕨類，但絕不限於此，實際它的應用極廣，它是種優化演算法，是種演算法設計思想，比如貪吃法和動態規劃，絕不會局限於某個應用領域。數據挖掘演算法太窄了，像apriori,k-mean等演算法都是針對關聯規則挖掘和聚類提出的具體演算法。

㈡ 推薦一些關於xml資料庫技術相關的書，最好對相關技術，比如查詢及其優化演算法有比較詳細描述的~多謝

計算機技術對電子商務的作用

電子商務是指通過互聯網完成的商務交易。作為依託互聯網發展起來的商業運作模式,與傳統商業比較給人們曾帶來過很多欣喜，但是隨著電子商務交易的不斷發展，暴露出了一些技術問題，如EDI（Electronic Data Interchange）中的問題等，使電子商務一度陷入舉步為艱的地步。
一、EDI在電子商務中的應用
聯合國EDIFACT培訓指南認為：「EDI指的是在最少的人工干預下，在貿易夥伴的計算機應用系統之間的標准格式數據的交換」。 EDI主要由UN/EDIFACT的基礎標准體系和開放式EDI基礎標准兩部分組成。它是EDI的核心標准體系。EDI主要是為完成企業間的數據交換而產生和應用的。雖然EDI的應用使企業之間大大減少了在交易中的時間、效率上的開銷，但是傳統的EDI卻仍然存在不少的缺陷：
1.實現EDI的成本過於昂貴
EDI通信方式有兩種：一種是在貿易夥伴之間建立專用網；另一種是增值網路(VAN)方式，建立專用網的費用是不言而喻的，而VAN是一套私有網路，它的租用、維護費用也是很昂貴的。對於中小型企業來說，這兩種方式的費用都是很難承受的。有數據顯示：全球使用EDI進行電子商務的企業98%來自世界前1000強。這樣也就限制了中小型企業加入到電子商務行列中的步伐，並有礙於電子商務全球化的進程。
2.EDI標准結構的靈活性較差
EDI使用的是一套預先定義好的報文標准，在與其他企業集成時不能隨業務環境的變化而進行自動的調整。這些不利於企業業務的發展。
3.EDI不能通過構建Web Service來跨越多個應用程序和供應商進行通信
在Web Service持續發展的今天，越來越多企業認識到了Web Service的巨大潛力,開始把它運用到他們的組織中，可是原有的EDI技術模式使企業無法利用EDI去實現這一目標。
4.EDI難以實現電子商務中的數據挖掘
EDI主要通過單證傳遞來完成企業之間信息交流，現在的電子商務已經不僅僅是停留在數據的傳遞上，而且要通過Web收集大量的、各種商業數據來進行數據挖掘，從中得到有利於企業戰略決策的信息。
二、XML在電子商務中的應用
1.XML的簡介
XML（eXtensible Markup Language）是W3C於1998年2月發布的一種標准，它是SGML的簡化子集，將SGML的功能和HTML的易用性結合到Web的應用中，以一種開放的自我描述方式定義數據結構，在描述數據內容的同時能突出對結構的描述，從而體現出數據之間的關系。
2.XML的特點
(1)XML成為不同格式數據向標准化格式數據轉換的「橋梁」。由於處於Web中的電子商務，其中涉及的很多數據源都是異構的，XML在各種數據源之間建立了一個數據格式的中間標准，利用XML中的XSLT技術實現了不同格式的數據與XML文檔之間的雙向轉換與傳輸，並方便地進行Web應用。
(2)文檔管理功能。XML中的XLL（eXtensible Linkage Language）技術是表示XML文檔之間的鏈接方法，XLL與HTML中的超鏈接相似，但功能更強，例如可以鏈接文檔的特定部分。此方法使文檔更易於檢索等，也可以使很多公司從海洋一樣的文書工作中解脫出來。
(3)XML可以成為信息存儲和管理的方式。XML可以很輕松地完成與很多類型的企業資料庫的交互操作，例如從SQL查詢中檢索XML數據以及修改XML數據記錄。這就使XML如同傳統的資料庫技術一樣，易於操作。
(4)XML可以完成企業之間業務數據的傳輸。各種業務數據是以XML格式在企業之間傳輸。與EDI相比，不僅可以完成從一種票據格式到另一種票據格式的轉換，還有多種企業需要的基於票據各種操作，而且過程簡單、快捷，成本低廉。
(5)可以完成基於Web的數據挖掘。主要分為數據挖掘和挖掘表示兩個部分。數據挖掘就是利用合適的挖掘演算法和已有的知識庫知識對統一的XML 文檔進行數據提取,可以採用諸如特徵抽取、關聯分析、屬性分類、聚類分析等方法實現。挖掘表示是指對挖掘出的Web 數據經過模式評估和解釋用適當的形式表現出來,例如圖形，以便於用戶理解和使用。

3.XML的缺點
雖然XML很好地解決了EDI技術中的一些缺陷，並且XML已經成為Internet上數據交換事實上的標准。主要基於它的優點：擴展性、自描述性、系統無關性、健壯性、形式與內容分離等。但通過實踐證明，它仍然不能構建Web服務來跨越多個應用程序和供應商進行通信。這也就促成了ebXML的誕生。
EML-EDI在電子商務中的應用：如果基於XML技術的諸多優點，而直接用它來完全替代原來的EDI，顯然會給企業帶來多方面的不利，比如：資金上、技術上等的影響。因此，產生了過度技術模式——XML-EDI。在EML-EDI的模式中，為了保護原有投資，大企業之間依舊採用原有的EDI系統，採用EDI/VAN交換數據。
ebXML在電子商務中的應用:ebXML是由UN/CEFACT和OASIS 兩家組織發起和制定的一個規范集, 這些規范共同實現了模塊化電子商務框架。ebXML的目標是實現跨行業的B2B、B2C商業貿易，甚至全球性的電子商務市場,使得不同規模和不同地區的企業可以通過交換基於XML格式的消息來合作和進行商業活動。
ebXML體系架構由許多部分組成,其主要有:
（1）消息服務:消息組成了商業夥伴間的交易對話,是商務過程的基礎。ebXML可以創建各種類型的消息,對各種消息提供支持,以確保安全可靠的交換有效負載。
(2)注冊庫或知識庫:是ebXML 體系結構的核心,用來注冊和存儲商業流程和商業信息模型等,它使得ebXML工作所需要的各種數據能夠統一存放,以便復用和保持一致性。
(3)貿易夥伴信息:描述貿易夥伴參與貿易活動所必須的信息,也是雙方進行電子商務的技術細節,包含貿易夥伴個人信息CPP 和CPP 基礎上雙方協商出來的CPA。
(4)商務流程規范:ebXML是建立在商務流程建模的基礎上,ebXML規范體系集中包含著定義描述商務流程和信息模型的標准機制BPSS（Business Process Specification Schema）,是企業雙方進行電子商務的商業細節。當企業要進行電子商務並決定採用ebXML 框架時,首先通過在注冊庫中查找,找到符合自己條件的商業模型,並下載ebXML的技術規范；然後按照該規范在本地系統上構建ebXML的應用實現,並創建一個合作夥伴概要CPP來描述企業系統的實現細節和提供的功能信息服務,可以加入新的商務流程,也可以只是引用已有的流程,隨後將其注冊到注冊中心。這樣其他採用ebXML標準的企業就可以通過注冊庫查找該企業的CPP,雙方系統在CPP的基礎上自動協商,最終達成CPA等交互協議約定,以後雙方便在此基礎上進行交易。
電子商務經歷了以上三種主要的、一種過度的計算機技術的發展，逐步走向完善。另外，從中我們可以看到，ebXML的開放性以及接納現有標准和方法的做法,使得它很易於被人們接受 ,而且ebXML 允許商家以不同的方式進行商業活動,因此具有更廣泛的市場和應用前景。
參考文獻：
[1]宋沛軍:電子商務概論[M].西安：西安電子科技大學出版社，2005
[2]陳堯妃倪應華:基於XML個性化數據挖掘框架設計[J].現代電子技術，2007 No.2
[3]沈世銘尹紹宏:基於XML在異構數據之間轉換的研究[J].儀器儀表用戶， 2007 No.1
[4]ebXML overview,
[5]郝萍饒若楠:一種基於MDA 的ebXML[J].計算機應用與軟體,2005 No.3

㈢ 資料庫的查詢優化演算法

不要在這里等，等不到的，祝你好運！

㈣ 第四十五章 SQL命令 FROM（一）

一個SELECT子句，指定要查詢的一個或多個表。

FROM 子句指定在 SELECT 語句中查詢數據的一個或多個表(或視圖或子查詢)。
如果沒有查詢表數據，則 FROM 子句是可選的，如下所述。

多個表被指定為逗號分隔的列表，或者由其他 JOIN 語法分隔的列表。
可以為每個表名提供一個別名。

在 SELECT 語句中為多個表指定欄位名時使用表名別名。
如果 FROM 子句中指定了兩個(或更多)表，可以通過指定 tablename 來指明需要哪個表的欄位。
SELECT SELECT -item 子句中每個欄位的欄位名。
由於表名通常是長名稱，因此短表名別名在此上下文中很有用( t-alias.fieldname )。

下面的示例展示了表名別名的使用:

AS關鍵字可以省略。
它是為了兼容性和清晰度而提供的。

table-ref 名稱可以是限定的( schema.tablename )或非限定的( tablename )。
非限定表名(或視圖名)的模式名使用模式搜索路徑或系統范圍的默認模式名提供:

當在 FROM 子句中指定多個表名時， SQL將對這些表執行連接操作。
執行的連接類型由每對表名之間的連接關鍵字短語或符號指定。
當兩個表名用逗號分隔時，將執行交叉連接。

執行連接的順序是由SQL查詢優化器自動確定的，而不是基於查詢中列出的表的順序。
如果需要，可以通過指定查詢優化選項來控制執行連接的順序。

以下三個 SELECT 語句顯示了兩個單獨表的行數，以及指定兩個表的 SELECT 的行數。後者產生一個更大的表，即笛卡爾乘積，其中第一個表中的每一行都與第二個表中的每一行相匹配，這一操作稱為交叉聯接( Cross Join )。

從 Sample.Company、Sample.Vendor 中選擇計數( * )

在大多數情況下，交叉連接的大量數據復制是不可取的，而某些其他類型的連接更可取。

如果在 SELECT 語句中指定 WHERE 子句，則執行交叉聯接，然後 WHERE 子句謂詞確定結果集。這等效於使用 ON 子句執行內聯接。因此，以下兩個示例返回相同的結果：

默認情況下， SQL查詢優化器使用復雜而靈活的演算法來優化涉及聯接操作和/或多個索引的復雜查詢的性能。在大多數情況下，這些默認值可提供最佳性能。但是，在極少數情況下，可能希望向查詢優化器提供「提示」，指定查詢優化的一個或多個方面。因此， SQL在 FROM 子句中提供了 OPTIMIZE-OPTION 關鍵字。可以按任意順序指定多個優化關鍵字，並以空格分隔。

可以在簡單的 SELECT 語句、 CREATE VIEW DEFINITION SELECT 語句或 FROM 子句的子查詢 SELECT 語句中使用 OPTIMIZE-OPTION FROM 子句關鍵字。

此可選關鍵字指定提供任何好處的所有索引都用於查詢聯接順序中的第一個表。只有在定義了多個索引時才應使用此關鍵字。優化器的默認設置是只使用優化器認為最有益的那些索引。默認情況下，這包括所有有效的相等索引和其他類型的選定索引。 %ALLINDEX 使用所有類型的所有可能有益的索引。測試所有索引的開銷較大，但在某些情況下，它可能會提供比默認優化更好的性能。當使用多個范圍條件索引和低效相等條件索引時，此選項特別有用。在這些情況下，查詢優化器可能無法獲得准確的索引選擇性。 %ALLINDEX 可以與 %IGNOREINDEX 一起使用，以包括/排除特定索引。通常， %ALLINDEX 不應與 TOP 子句查詢一起使用。

可以將 %STARTTABLE 與 %ALLINDEX 配合使用，以指定 %ALLINDEX 應用於哪個表。

可以使用 %NOINDEX 條件級別提示為特定條件的 %ALLINDEX 指定異常。
%NOINDEX 提示放置在不應該使用索引的每個查詢選擇條件的前面。
例如， WHERE %NOINDEX hiredate < ? 。
這在絕大多數數據沒有被排除的情況下最常用。
對於小於( < )或大於( > )條件，使用%NOINDEX條件級別提示通常是有益的。
對於相等條件，使用 %NOINDEX 條件級提示沒有任何好處。
對於連接條件， ON 子句連接支持 %NOINDEX 。

此可選關鍵字指定查詢優化器應開始使用指定的表名執行聯接。 tablename 為稍後在聯接序列中指定的表命名。其餘表的聯接順序留給查詢優化器。此提示在功能上與 %STARTTABLE 相同，但為提供了以任意順序指定聯接表序列的靈活性。

tablename 必須是簡單標識符，可以是表別名，也可以是非限定表名。不能使用限定表名（ schema.table ）。如果查詢指定了表別名，則必須將該表別名用作表名。例如：

%FIRSTTABLE 和 %STARTTABLE 都允許指定用於聯接操作的初始表。 %INORDER 允許指定用於聯接操作的所有表的順序。這三個關鍵詞是相互排斥的；只指定一個和一個。如果不使用這些關鍵字，查詢優化器將按照其認為最佳的順序對表執行聯接，而不管這些表的列出順序如何。

不能使用 %FIRSTTABLE 或 %STARTTABLE 從左外部聯接的右側（或右外部聯接的左側）開始聯接順序。嘗試這樣做會導致 SQLCODE-34 錯誤：「優化器無法找到可用的聯接順序」。

此可選關鍵字指定編譯器優化器檢查所有可選聯接序列以最大化訪問性能。例如，在創建存儲過程時，增加的編譯時間可能值得提供更優化的訪問。默認優化是，當 FROM 子句中有許多表時，不檢查不太可能的連接序列。 %FULL 將覆蓋此默認行為。

當 FROM 子句包含使用箭頭語法訪問的表時，可以同時指定 %INORDER 和 %FULL 關鍵字，這些表的順序不受約束。

此可選關鍵字指定查詢優化器忽略指定的索引或索引列表。(為了向後兼容，支持不推薦使用的同義詞 %IGNOREINDICES 。)

在此關鍵字後面指定一個或多個索引名。多個索引名必須用逗號分隔。可以使用以下格式之一指定索引名：

方案名和表名是可選的。如果省略，則使用當前默認架構和指定為 from table-ref 的表名。星號( * )通配符指定指定表的所有索引名。可以按任意順序指定索引名稱。 SQL不會驗證指定的索引名(或它們的模式名和表名)；不存在或重復的索引名將被忽略。

通過使用此優化約束，可以使查詢優化器不使用對特定查詢不是最佳的索引。通過指定除一個索引名之外的所有索引名，實際上可以強制查詢優化器使用剩餘的索引。

還可以通過在條件前面加上 %noindex 關鍵字來忽略特定條件表達式的特定索引。

此可選關鍵字指定查詢優化器按照表在 FROM 子句中列出的順序執行聯接。這最大限度地減少了編譯時間。子查詢的扁平化和索引使用不受影響。

%INORDER 不能與交叉聯接或右外部聯接一起使用。如果指定的表順序與外部聯接的要求不一致，則會生成 SQLCODE-34 錯誤：「Optimizer找不到可用的聯接順序。」為避免這種情況，建議在與外部聯接一起使用 %INORDER 時，僅與ANSI樣式的左外部聯接或完全外部聯接一起使用。

視圖和表子查詢按照它們在 FROM 子句中指定的順序進行處理。

將此關鍵字與 %FIRSTTABLE 和 %STARTTABLE 進行比較，這兩個關鍵字都只指定初始連接表，而不指定完整的連接順序。

不能同時使用 %INORDER 和 %PARALLEL 優化；如果同時指定了這兩個優化，則忽略 %PARALLEL 。

此可選關鍵字在量化的子查詢(返回布爾值的子查詢)的 FROM 子句中指定。它指定編譯器優化器應抑制子查詢展平。此優化選項禁用「扁平化」(默認)，它通過將子查詢有效地集成子查詢到查詢中來優化包含量化的子查詢的查詢：將子查詢的表添加到查詢的 FROM 子句中，並將子查詢中的條件轉換為查詢的 WHERE 子句中的聯接或限制。

以下是使用 %NOFLATTEN 的量化子查詢的示例：

%INORDER 和 %STARTTABLE 優化隱式指定 %NOFLATTEN 。

此可選關鍵字在子查詢的 FROM 子句中指定。它指定編譯器優化器應該禁止子查詢到視圖的轉換。此優化選項通過將子查詢作為內聯視圖添加到查詢的 FROM 子句來禁用對包含子查詢的查詢的優化；子查詢與查詢欄位的比較將作為聯接移動到查詢的 WHERE 子句。

此可選關鍵字在流式子查詢的 FROM 子句中指定-返回行的結果集的子查詢，即封閉查詢的 FROM 子句中的子查詢。它指定編譯器優化器應該禁止將子查詢(或視圖)合並到包含查詢中。

在下面的示例中，查詢優化器通常會通過對子查詢執行 Sample.Person 的笛卡爾乘積聯接來「減少」該查詢。 %NOREDUCE 優化選項可防止出現這種情況。 IRIS改為在 GNAME 上構建臨時索引，並在此臨時索引上執行聯接：

此可選關鍵字在量化的子查詢(返回布爾值的子查詢)的 FROM 子句中指定。它指定編譯器優化器應禁止集值子查詢優化( SVSO )。

在大多數情況下，集值子查詢優化可以提高 [NOT] EXISTS 和 [NOT] In 子查詢的性能，特別是對於只有一個可分離關聯條件的子查詢。
它通過用滿足條件的數據值填充臨時索引來實現這一點。
IRIS不是重復執行子查詢，而是在臨時索引中查找這些值。
例如， SVSO 優化了 NOT EXISTS (SELECT P.num FROM Procts P WHERE S.num=P.num AND P.color='Pink') ，創建臨時索引。

SVSO 優化了 ALL 或 ANY 關鍵字與相對操作符( > ， >= ， < ，或 <= )和子查詢的子查詢，如 … WHERE S.num > ALL (SELECT P.num…)
它通過將子查詢表達式 sqbExpr (在本例中為 P.num )替換為 MIN(sqbExpr) 或 MAX(sqbExpr) 來實現這一點。
當 sqbExpr 上有索引時，它支持快速計算。

%INORDER 和 %STARTTABLE 優化不禁止集值子查詢優化。

當使用帶有 ORDER BY 子句的 TOP 子句時指定此可選關鍵字。
默認情況下， TOP 和 ORDER By 優化到第一行的最快時間。
相反，指定 %NOTOPOPT (沒有 TOP 優化)將優化查詢，以最快地檢索完整的結果集。

此可選關鍵字在查詢或子查詢的 FROM 子句中指定。
它禁用為多個 OR 條件和針對 UNION 查詢表達式的子查詢提供的自動優化。
這些自動優化將多個 OR 條件轉換為 UNION 子查詢，或將 UNION 子查詢轉換為 OR 條件。
這些 UNION/OR 轉換允許 EXISTS 和其他低級謂詞遷移到頂級條件，以便IRIS查詢優化器索引使用它們。
這些默認轉換在大多數情況下都是可取的。

然而，在某些情況下，這些 UNION/OR 轉換會帶來很大的開銷負擔。
%NOUNIONOROPT 對與此 FROM 子句關聯的 WHERE 子句中的所有條件禁用這些自動 UNION/OR 轉換。
因此，在一個復雜的查詢中，可以對一個子查詢禁用這些自動UNION/OR優化，同時在其他子查詢中允許它們。

UNION %PARALLEL 關鍵字禁用自動 UNION-to- or 優化。

%INORDER 和 %STARTTABLE 優化抑制了 OR-to-UNION 優化。
%INORDER 和 %STARTTABLE 優化不抑制 UNION-to-OR 優化。

㈤ 理想汽車s7崗位是什麼

理想汽車s7崗位是負責自動駕駛深度學習演算法的推理和訓練框架研發，模型優化和部署。查詢理想汽車各家企業的招聘信息顯示s7崗位是負責自動駕駛深度學習演算法的推理和訓練框架研發，模型優化和部署，職位要求如下：
1、扎實的C++/Python編程基礎，熟悉常用數據結構和演算法，熟悉軟體設計模式；
2、較強的演算法實現能力，至少熟練使用Pytorch、Tensorflow、MXNet等深度學習框架之一；
3、具有TensorRT工程化或其他深度學習推理引擎者優先；
4、具有異構計算優化經驗優先（CUDA/OpenCL/NEON等）；
5、計算機相關專業碩士以上學歷，有自動駕駛研發經驗者優先；
6、具有優秀的分析問題和解決問題的能力，對解決具有挑戰性的問題充滿激情；
7、對新技術有持續熱情，善於快速學習，個性樂觀，善於與人溝通合作。

㈥ 實現關系代數表達式的優化演算法 。 輸入：關系代數表達式或SELECT查詢語句 輸出：優化後的關系代數表達式

vt.
1. 選擇; 挑選；選拔
adj.
1. 精選的；挑選出來的；作為…精華的；優等的2. 限制性的, 選擇嚴格的3. （社團、俱樂部、地方等）有錢、有社會地位的人使用的 4. 傑出的，優秀的
vi.
1. 挑選，選擇；做出選擇

㈦ 求php多級菜單數據查詢及展示代碼的演算法優化（全部分奉上）

publicfunctionempowerList(){
			$sql="selectueid,pid,name,,ueidASC";
			$datas=$this->db->getAll($sql);
			$list=array();
			if(!empty($datas)){
				foreach($datasas$k=>$v){
					$list[$v['pid']][]=$v;
				}
			}
			return$list;
		}

然後你在根據$list的結構組織一下頁面顯示就好了

㈧ Rocchio演算法的Rocchio演算法簡介

Rocchio 演算法是IR中通過查詢的初始匹配文檔對原始查詢進行修改以優化查詢的方法。Rocchio 演算法。該演算法（Rocchio，1971）是20 世紀70 年代左右在Salton 的SMART 系統中引入並廣泛流傳的一種相關反饋演算法。

㈨ 數據結構和演算法優化

APP的優化是任重而道遠的過程，必須在意每一個環節，否者當你想要優化的時候，發現到處都是坑，已經不知道填補哪裡了，所以我們必須一點一滴的做起。

數據結構和演算法優化

能帶來什麼好處呢？他能使得你程序獲得數據更快，內存佔用更合理。最終體現為響應快內存佔用小。

我們先看常見的數據結構類型特點

數組 ： 一片物理上連續的大小確定的儲存空間 。int[num]

順序表 ：物理上連續、邏輯上連續、大小可以動態增加。ArrayList （查找快，添加刪除慢）

鏈表 ：物理上不連續、邏輯上連續、可以動態增加和刪除節點。LinkedList （查找慢只能輪尋，增加刪除快）

物理上連續：數組或者鏈表在初始化的時候，會申請分配內存空間：只要存儲空間足夠你申請的大小就分配給你初始化（物理不連續）；必須要連續的存儲空間，我才給你分配，否則失敗（物理上連續）

那麼有沒有繼承純虛標和鏈表的2個有點的數據結構呢？HashMap！     

HashMap

它是由數組和鏈表結合組成。（HashMap：JDK1.7之前 24 之前： 數組+ 鏈表； HashMap：JDK1.8 之後：  數組+ 鏈表 + 紅黑樹）

下面是HashMap結構圖

它是怎麼操作的呢？為什麼他能同時擁有順序表和鏈表的優點呢？  搞清它的實現方式，我們就可以知道了， 大致可以分為以下的步驟。

①put方法，傳入object和value，通過hash運算得到一個int類型的hashcode，這里假設為X（後續X為這個hashcode）。

②hashmap內部是有一個table數組+鏈表形成的。我們拿到這個X後，使用X/table.length(hashcode值/table[].length),得到一個小於table.length的值M，該值就是這個value應該放置的數組位置。我們准備把value放入table[M]中。

③我們把hashcode和value打包為一個node節點(為什麼需要這么打包後續會提到),准備存入table[M]中。

④出入table數組的鏈表中有2種方式：

前插方式：不管數組table[M]節點有值與否，都把這個准備插入的node節點作為數組的根節點。可能出現2種情況：

（1）如果table[M]節點沒有值，則node節點作為數組的根節點。

（2）如果table[M]節點已存在數據鏈表，就把這些數據鏈表，鏈到這個准備插入的node節點上，以弄得節點為根節點放入table[M中]。

後插方式：可能會出現的2種情況

  (1)   如果table[M]節點沒有值，則node節點作為數組的根節點。

（2）如果table[M]節點已存在數據鏈表，則把node節點鏈到該數據鏈表的最後一個節點上。

經歷以上4個步驟就完成了hashmap的插入操作，現在解釋一下為什麼要打包為node節點。

舉個栗子，假如hashmap.length=16,我們准備存入ObjectA(OA)和ObjectB(OB),假設OA經過hash運算得到的hashcode是1，OB經過hash運算得到hashcode是17，OA和OB進行求模運算結果都為1，鏈到鏈表上時，我們get方法的時候怎麼取到正確的值呢，因為鏈表上的模運算都是1.這個時候我們就需要通過hashcode來識別這個鏈表上的哪個值是OA的value哪個是OB的value，因為我們已經把hashcode和value打包起來了。

補充

hashmap的table數組的大小事是2的次冪（不要問為什麼，源碼定的，他們肯定經過大量的統計或者運算，這是科學）。table數組默認的長度是16，也就是說你new一個空的hashmap長度為16，當然也提供了一個給你設置長度的方法，但是假如你設置17，則長度會為32，這不難理解。

hash碰撞

hash碰撞就是，假如OA、OB...ON經過模運算得到的數組位置相同，那麼他們都會掛在這個數組節點的鏈表上，極端情況想整個hashmap看起來像單鏈表。但這種情況這並不是我們想要的結果。我們可以通過擴容來盡可能的避免hash碰撞。

擴容 ：（意義，在於避免大量的hash碰撞，因為在某些極端情況下，有點像單鏈表）

閾值 ：閾值=table.length* DEFAULT_LOAD_FACTOR （擴容系數，默認為0.75，也可以自己設定，一般不做修改）

hashmap定義：當hashmap中的元素個數超過閾值大小時，我們就需要對table數組進行2倍擴容，如從16→32。

注意：擴容後hashmap會調用resize()，對hashmap內的數據重新計算所有元素的位置 。 。因為假如你之前17/16=1，現在17/32=17，你的位置發生變化了。

缺點 ：

hashMap因為有閾值的擴容機制，所以一定會有空間浪費，比如0.75的時候，一定有25%空間被浪費掉了。空間換時間。

hashmap是線程不安全的。因為可能在一個線程擴容（resize（）方法執行）的情況下,另外一個線程在get，但是拿不到之前的數據了，因為擴容。所以是線程不安全的。或者線程擴容（resize（）方法執行時，多線程進行put的時候導致的多線程數據不一致。

如何線程安全的使用HashMap?使用使用鎖分段技術或者使用HashTable(Hashtable的方法是Synchronize的，而HashMap不是,其實也就是鎖機制起作用)。

SparseArray（Android為了優化內存所提供的api）

特性：key為int,value為object，二分查找的思想，雙數組，刪除的時候節點不刪除，而是把value刪除，避免刪除的時候數組還要移動。

SparseArray比HashMap更省內存，在某些條件下性能更好，主要是因為它避免了對key的自動裝箱（int轉為Integer類型），它內部則是通過兩個數組來進行數據存儲的，一個存儲key，另外一個存儲value，為了優化性能，它內部對數據還採取了壓縮的方式來表示稀疏數組的數據，從而節約內存空間，我們從源碼中可以看到key和value分別是用數組表示。

為什麼是能夠進行二分查找呢？從源碼上看key和value分別是用int類型數組和object數組表示，所以這也是SparseArray的局限性。

 private int[] mKeys;

 private Object[] mValues;

為什麼說SparseArray比HashMap更省內存，在某些條件下性能更好？

因為SparseArray有以下一個特性，首先它是2個數組，在數據查找的時候無疑會比hashmap快很多，其次在刪除的時候，SparseArray並不會把數組key位置進行刪除，而是把key的索引value置位DELETE標志（這樣就避免了數組delete操作後的array的操作）。當我們下次進行插入的時候，若要插入的位置key的索引value為DELETE標志，則把數據覆蓋給value（只是經歷了set操作，並無其他操作）。否則進行add操作（包含array）。

所以經過以上的情況，我們可以看出，SparseArray相對於HashMap,會越用越快。

缺點

（1）SparseArray僅僅能存儲key為int類型的數據。

（2）插入操作需要復制數組，增刪效率降低 數據量巨大時，復制數組成本巨大，gc()成本也巨大。

（3）數據量巨大時，查詢效率也會明顯下降。

（4）線程不安全問題，類似hashmap

一般我們在滿足下面兩個條件我們可以使用SparseArray代替HashMap：

（1）數據量不大，最好在千級以內

（2）key必須為int類型，這中情況下的HashMap可以用SparseArray代替：

ArrayMap（Android為了優化內存所提供的api）

ArrayMap和SparseArray差不多，不同的是key類型可以是object類型。

ArrayMap的2個數組，一個數組記錄key的hash值，另外一個數組記錄Value值。其他存儲方式和運行思想和SparseArray一致。

線程不安全:hashmap、ArrayMap、SparseArray