①、table数组大小是由capacity这个参数确定的，默认是16，也可以构造时传入，最大限制是1<<30；②、loadFactor是装载因子，主要目的是用来确认table数组是否需要动态扩展，默认值是0.75，比如table数组大小为16，装载因子为0.75时，threshold就是12，当table的实际大小超过12时，table就需要动态扩容；③、扩容时，调用resize()方法，将table长度变为原来的两倍（注意是table长度，而不是threshold）④、如果数据很大的情况下，扩展时将会带来性能的损失，在性能要求很高的地方，这种损失很可能很致命。

①、HashMap是线程不安全的，HashTable是线程安全的；②、由于线程安全，所以HashTable的效率比不上HashMap；③、HashMap最多只允许一条记录的键为null，允许多条记录的值为null，而HashTable不允许；④、HashMap默认初始化数组的大小为16，HashTable为11，前者扩容时，扩大两倍，后者扩大两倍+1；⑤、HashMap需要重新计算hash值，而HashTable直接使用对象的hashCode

ConcurrentHashMap类（是Java并发包java.util.concurrent中提供的一个线程安全且高效的HashMap实现）。HashTable是使用synchronize关键字加锁的原理（就是对对象加锁）；而针对ConcurrentHashMap，在JDK1.7中采用分段锁的方式；JDK1.8中直接采用了CAS（无锁算法）+synchronized。

除了加锁，原理上无太大区别。另外，HashMap的键值对允许有null，但是ConCurrentHashMap都不允许。

HashTable使用一把锁（锁住整个链表结构）处理并发问题，多个线程竞争一把锁，容易阻塞；ConcurrentHashMapJDK1.7中使用分段锁（ReentrantLock+Segment+HashEntry），相当于把一个HashMap分成多个段，每段分配一把锁，这样支持多线程访问。

①、table数组大小是由capacity这个参数确定的，默认是16，也可以构造时传入，最大限制是1<<30；②、loadFactor是装载因子，主要目的是用来确认table数组是否需要动态扩展，默认值是0.75，比如table数组大小为16，装载因子为0.75时，threshold就是12，当table的实际大小超过12时，table就需要动态扩容；③、扩容时，调用resize()方法，将table长度变为原来的两倍（注意是table长度，而不是threshold）④、如果数据很大的情况下，扩展时将会带来性能的损失，在性能要求很高的地方，这种损失很可能很致命。

因为hashCode相同，不一定就是相等的（equals方法比较），所以两个对象所在数组的下标相同，"碰撞"就此发生。又因为HashMap使用链表存储对象，这个Node会存储到链表中。

1、去掉ie设置中的第三方支持取消掉。2、在系统属性－高级－性能－数据执行保护中，添加loadrunner安装目录中的vugen.exe文件。遇到flight界面为空的解决的可能方法：1、如果安装了IE以外的浏览器，并且IE不是默认浏览器，则无法生成录制脚本2、如果录制脚本时IE不能打开，则需要将浏览器的IE工具高级选项中，将“启用第三方浏览器扩展”的勾选去掉3、lr自带的webtours系统，如果点击Flights选项，出现空白页面，请检查本机oracle的PERL5LIB环境变量，我的解决办法是使用webtours的时候删除掉该变量的内容，使用oracle的时候再填上该变量内容为什么该变量会影响webtours的使用，原因不明

原因：可能是缺少包头。默认情况下是不录制HTTPHeader（请求包头），如果有些数据存放在Header中，导致脚本无法正常通过；解决：利用抓包工具（如HttpWatch），进行抓包分析，找到报头，在请求前添加该报头。如：web_add_auto_header("x-requested-with","XMLHttpRequest")；查找缺少的报头名，添加包头。在录制中打开Options（选项）→Advanced（高级）→Headers（标题）→Recourdheadersinlist→添加包头。

造成这种情况的主要原因是LoadRunner8.0的VuGen在录制WebService协议的脚本时存在一个缺陷：如果服务器的操作系统是中文的，VuGen会自动将WSDL文件的头改为，因此会有上面的错误提示。解决方法：把“LR80WebservicesFPI_setup.exe”和“lrunner_web_sevices_path_1.exe”两个补丁打上即可解决。