JAVA基础知识

arraylist:

            用数组实现，允许所有元素包括null,自动增加容量大小，但是不是线程安全的，如果有多个线程访问同一个arraylist实例，并且其中有一个线程修改了其结构那么需要在外部同步。与linkedlist相比arraylist查找速度相对较快但是存储速度较慢。

 

linkedlist:

              用带头和尾指针的双链表实现。允许所有元素包括null.遍历时将根据索引距离头和尾的长度而选择从头或者尾遍历。不是线程安全的。与arraylist相比较查找元素速度较慢，但是添加或者删除速度较快。

 

hashmap:

              基于哈希表的映射实现。不保证映射的顺序不变。允许null值和null键，但是键值不能重复。不是线程安全的。但是可以通过Collections类的静态的synchronizedMap()方法，创建一个线程安全的Map对象，并把它作为一个封装的对象来返回。

 

hashtable:

              基于哈希表的映射实现。允许任何对象作为键或者值，但是键和值都不能为null,使用时作为键的元素必须实现hashcode和equals方法。是线程安全的。

 

hashset:

            基于哈希表的实现(实际上是一个hashmap实例)。允许所有元素包括null，但是不允许重复。并且存储在其内部的元素具有无序性。不是县城安全的，但是可以通过静态方法Collections.synchronizedSet()包装实现其线程安全。

 

多线程：

           进程的缩小版，实现一个应用程序并发执行多个任务，进而提升计算机性能，多个线程间能共享数据，但是每个线程也都有自己私有的数据。在为了提升速度在每个线程执行期间每个线程都有一个存储空间，用来拷贝在主存储空间的数据，而每个线程一般都在自己独立的存储空间操作，但是又时也会和主线程同步数据。但是这造成了读取过期数据，数据不可见，线程死锁等问题。而解决方法就是用单一线程化，数据单线程化，创建线程变量，线程锁等。

 

 

ClassLoader的工作原理:在Java内部实现了三种类型的ClassLoader：Bootstrap ClassLoader，Extension ClassLoader， System ClassLoader。这三个ClassLoader通过parent形成一条单向链，其中Bootstrap处于链尾，而System ClassLoader处于链头。

Bootstrap ClassLoader:

                                      Bootstrap ClassLoader用于在启动JVM时加载类，以使JVM能正常工作，因而它是用Native代码实现的，最早被创建出来，处于最底层。Bootstrap ClassLoader将搜索Java核心库（%JAVA_HOME%\jre\lib），如rt.jar、i18n.jar等，在这些核心库中包含了Java的核心类，即Bootstrap ClassLoader用于加载Java的核心类，包括java.lang、java.io等包中的类。

Extension ClassLoader:

                                     Extension ClassLoader位于链的中间层，它将搜索特定的标准扩展目录。该标准扩展目录在不同的JVM实现中不一定相同，在sun的JVM中，它是%JRE_HOME% \lib\ext，具体路径可以通过java.ext.dirs系统属性值获取。该标准扩展目录存在的目的在于扩展和共享，应用程序厂商可以将部分共享库放置于此，而不是各自程序的目录下的多份拷贝。在开发过程中，我们也可以把部分常用的库放置于此，而不必每次都去配置环境。

System ClassLoader:

                                    System ClassLoader位于链的最顶层，它将搜索CLASSPATH中配置的目录和jar文件。

三种ClassLoader的协同工作:

                                    既然系统中有三种不同的ClassLoader，那么一个类的加载是用那个ClassLoader呢？在Java中，是通过“代理模型（delegation model）”来决定使用哪个ClassLoader来加载类的（读取.class文件，并创建相应的Class对象）。当一个类需要被加载的时候，系统默认通过System ClassLoader来加载该类；然而System ClassLoader并不立即加载该类，它会将加载的行为代理给其parent去加载，只有当其parent不能加载该类的时，System ClassLoader才去搜索CLASSPATH中的目录和jar文件以加载该类，若找到对应的.class文件，则加载该类，否则抛出ClassNotFoundException。当它将加载的行为代理给Extension ClassLoader并最终代理给Bootstrap ClassLoader的时候，他们也做的是相似的事情。从设计的角度，这其实就是一种职责链模式（Chain of Responsibility Pattern）。

 

那么Java为什么需要这种代理模型呢？答案是出于安全的考虑。Java是一种安全的编程语言，它会对每个加载的类执行安全检查，但是对Java核心库中的类是不执行安全检查的（即他们是受JVM信赖的）。（什么是安全检查？以我现在所知，就是用户可以通过security manager来控制特定目录的访问权限，如何使用这些控制将会是另一个主题。对安全检查是否还有其他的呢？）那么假如用户可以加载自己编写的和核心库同名的类（如java.lang.Object），那么这些用户编写的类就可以绕过安全检查，从而为一些恶意用户提供了一种破坏的途径。然而在使用这种代理模型后，类的加载首先会代理到Bootstrap ClassLoader中实行加载，如果它发现当前核心类库中可以加载对应的类，系统会加载核心库中的类，而不会加载用户编写的类。