正确答案是AA因为put的时间是有序的，直接循环输出map的值就是有序的B循环输出后，再通过额外的循环逻辑代码进行排序输出C实现类改为使用LinkedHashMap,再进行put操作D不建议使用map进行直接的有序排列首先要明确HashMap底层是hash排列的，也就不是类似链表的直接有序插入排序的，所以put操作和输出并不是完全一致的。所以A选项是错误的B选项是指把map转化成list等结构，再进行排序C和D是针对有序Map实现类的描述，可以实现但是性能不好，不建议

java的集合类型主要有3种：set(集)、list(列表)和map(映射)。1、List(有序、可重复)List里存放的对象是有序的，同时也是可以重复的，List关注的是索引，拥有一系列和索引相关的方法，查询速度快。因为往list集合里插入或删除数据时，会伴随着后面数据的移动，所有插入删除数据速度慢。2、Set(无序、不能重复)Set里存放的对象是无序，不能重复的，集合中的对象不按特定的方式排序，只是简单地把对象加入集合中。3、Map(键值对、键唯一、值不唯一)Map集合中存储的是键值对，键不能重复，值可以重复。根据键得到值，对map集合遍历时先得到键的set集合，对set集合进行遍历，得到相应的值。

DK7是数组+链表，JDK8是数组+链表/红黑树。1、链表插入方式的不同在1.7之前，链表元素的插入采用的是头插法，也就是说，当有新结点进来时，会在插入在链表的头部。很明显，由于不用遍历链表，这种插入方式的效率是更高的。但是1.8之后，因为当结点插入的时候，本身就要为了判断元素的个数而遍历链表（看看是否达到了树化的阈值），所以就可以搭一个顺风车，在遍历完之后，把结点插入到链表尾部，即采用的尾插法。这种方式也解决了多线程下可能引发的死锁问题。因为头插法的链表在扩容移动时，会被逆序，即后插入的先被处理，如果这个时候有另一线程进行get操作，就有可能引发死锁2、插入时机不同1.7之前是扩容后再插入新的数据，并且不会先计算插入值的哈希值，最后单独算。1.8之后是先插入再扩容，插入的值和大家一起计算新的哈希值。

1.两者父类不同HashMap是继承自AbstractMap类，Hashtable是继承自Dictionary类。不过它们都实现了同时实现了map、Cloneable（可复制）、Serializable（可序列化）这三个接口。2.对外提供的接口不同Hashtable比HashMap多提供了elments()和contains()两个方法。elments()方法继承自ashtable的父类Dictionnary。elements()方法用于返回此Hashtable中的value的枚举。contains()方法判断该Hashtable是否包含传入的value。它的作用与containsValue()一致。事实上，contansValue()就只是调用了一下contains()方法。3.对null的支持不同Hashtable：key和value都不能为null。HashMap：key可以为null，但是这样的key只能有一个，因为必须保证key的唯一性；可以有多个key值对应的value为null。4.安全性不同HashMap是线程不安全的，在多线程并发的环境下，可能会产生死锁等问题，因此需要开发人员自己处理多线程的安全问题。Hashtable是线程安全的，它的每个方法上都有synchronized关键字，因此可直接用于多线程中。虽然HashMap是线程不安全的，但是它的效率远远高于Hashtable，这样设计是合理的，因为大部分的使用场景都是单线程。当需要多线程操作的时候可以使用线程安全的ConcurrentHashMap。ConcurrentHashMap虽然也是线程安全的，但是它的效率比Hashtable要高好多倍。因为ConcurrentHashMap使用了分段锁，并不对整个数据进行锁定。5.初始容量大小和每次扩充容量大小不同6.计算hash值的方法不同

树化条件：HashMap具体实现类中有两个变量staticfinalintTREEIFY_THRESHOLD=8;staticfinalintMIN_TREEIFY_CAPACITY=64;哈希表的链表树化成红黑树有两个条件： 链表长度大于TREEIFY_THRESHOLD 哈希数组的长度大于MIN_TREEIFY_CAPACITY退化条件：扩容resize()时，红黑树拆分成的lo和hi两颗红黑树，每一颗树的结点数小于等于临界值6时退化成链表。移除元素remove()时，在removeTreeNode()方***检查红黑树是否满足退化条件，与结点数无关。如果红黑树根root为空，或者root的左子树/右子树为空，root.left.left根的左子树的左子树为空，都会发生红黑树退化成链表。

在JDK1.7以及1.7版本之前，HashMap对数组元素即链表的查询确实是从头节点开始查询的，这样链表一旦长了，效率比较低也是意料之中。而在1.8中对HashMap的数据结构进行了一定的优化，其中增加了一个阈值对数组元素进行判断是否有必要进行红黑树变形（红黑树是一种二叉查找树），一旦链表长度达到了阈值，其数据结构便会变形为红黑树，提高了查询效率，但插入的效率并没有链表头插法那么高，这也可能是HashMap底层为什么不用红黑树组成的数组的原因之一。性能对比：链表：插入复杂度O(1)，查找复杂度O(n)红黑树：插入复杂度O(logn)，查找复杂度O(logn)HashMap数组元素为链表的时候，插入直接使用头插，插入复杂度O(1)；当链表较短时候，查找数据时对性能并没有什么影响，如果链表一长，查找起来就很影响性能了。在Java8中，如果链表长度到达了8个，就会转化为红黑树，提高了查找的性能，但每次插入新的数据，都得维护红黑树的结构，复杂度为O(logn)。这样算是对查找和插入元素时性能的一个权衡，毕竟存起来就是用来查的。

concurrentHashMap融合了hashmap和hashtable的优势，hashmap是不同步的，但是单线程情况下效率高，hashtable是同步的同步情况下保证程序执行的正确性。但hashtable每次同步执行的时候都要锁住整个结构，如下图：concurrentHashMap锁的方式是细粒度的。concurrentHashMap将hash分为16个桶（默认值），诸如get、put、remove等常用操作只锁住当前需要用到的桶。concurrentHashMap的读取并发，因为读取的大多数时候都没有锁定，所以读取操作几乎是完全的并发操作，只是在求size时才需要锁定整个hash。而且在迭代时，concurrentHashMap使用了不同于传统集合的快速失败迭代器的另一种迭代方式，弱一致迭代器。在这种方式中，当iterator被创建后集合再发生改变就不会抛出ConcurrentModificationException，取而代之的是在改变时new新的数据而不是影响原来的数据，iterator完成后再讲头指针替代为新的数据，这样iterator时使用的是原来的数据。

1.减少内存开销假设使用可重入锁来获得同步支持，那么每个节点都需要通过继承AQS来获得同步支持。但并不是每个节点都需要获得同步支持的，只有链表的头节点（红黑树的根节点）需要同步，这无疑带来了巨大内存浪费。2.获得JVM的支持可重入锁毕竟是API这个级别的，后续的性能优化空间很小。synchronized则是JVM直接支持的，JVM能够在运行时作出相应的优化措施：锁粗化、锁消除、锁自旋等等。这就使得synchronized能够随着JDK版本的升级而不改动代码的前提下获得性能上的提升。

ConcurrentHashMap的原理是引用了内部的Segment(ReentrantLock)分段锁，保证在操作不同段map的时候，可以并发执行，操作同段map的时候，进行锁的竞争和等待。从而达到线程安全，且效率大于synchronized。但是在Java8之后，JDK却弃用了这个策略，重新使用了synchronized+CAS。弃用原因通过JDK的源码和官方文档看来，他们认为的弃用分段锁的原因由以下几点：1.加入多个分段锁浪费内存空间。2.生产环境中，map在放入时竞争同一个锁的概率非常小，分段锁反而会造成更新等操作的长时间等待。3.为了提高GC的效率4.新的同步方案

String[]arr={"zs","ls","ww"};List<String>list=Arrays.asList(arr);System.out.println(list);ArrayList<String>list1=newArrayList<String>();list1.add("张三");list1.add("李四");list1.add("王五");String[]arr1=list1.toArray(newString[list1.size()]);System.out.println(arr1);for(inti=0;i<arr1.length;i++){System.out.println(arr1[i]);}