查询优化算法

㈠ 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