equals和==的区别
Java中equals和==的区别
java中的数据类型，可分为两类：
1.基本数据类型，也称原始数据类型。byte,short,char,int,long,float,double,boolean
他们之间的比较，应用双等号（==）,比较的是他们的值。
2.复合数据类型(类)
当他们用（==）进行比较的时候，比较的是他们在内存中的存放地址，所以，除非是同一个new出来的对象，他们的比较后的结果为true，否则比较后结果为false。 JAVA当中所有的类都是继承于Object这个基类的，在Object中的基类中定义了一个equals的方法，这个方法的初始行为是比较对象的内存地 址，但在一些类库当中这个方法被覆盖掉了，如String,Integer,Date在这些类当中equals有其自身的实现，而不再是比较类在堆内存中的存放地址了。
对于复合数据类型之间进行equals比较，在没有覆写equals方法的情况下，他们之间的比较还是基于他们在内存中的存放位置的地址值的，因为Object的equals方法也是用双等号（==）进行比较的，所以比较后的结果跟双等号（==）的结果相同。
1 public class TestString {
2 public static void main(String[] args) {
3 String s1 = "Monday";
4 String s2 = "Monday";
5 if (s1 == s2)
6 {
7 System.out.println("s1 == s2");}
8 else{
9 System.out.println("s1 != s2");}
10 }
11 }
编译并运行程序，输出：s1 == s2说明：s1 与 s2 引用同一个 String 对象 -- "Monday"!
2.再稍微改动一下程序，会有更奇怪的发现：
public class TestString {
public static void main(String[] args) {
String s1 = "Monday";
String s2 = new String("Monday");
if (s1 == s2)
{System.out.println("s1 == s2");}
else
{System.out.println("s1 != s2");}
if (s1.equals(s2)) {System.out.println("s1 equals s2");}
else{
System.out.println("s1 not equals s2");}
}
}
我们将s2用new操作符创建
程序输出：
s1 != s2
s1 equals s2
说明：s1 s2分别引用了两个"Monday"String对象
3. 字符串缓冲池
原来，程序在运行的时候会创建一个字符串缓冲池当使用 s2 = "Monday" 这样的表达是创建字符串的时候，程序首先会在这个String缓冲池中寻找相同值的对象，在第一个程序中，s1先被放到了池中，所以在s2被创建的时候，程序找到了具有相同值的 s1
将s2引用s1所引用的对象"Monday"
第二段程序中，使用了 new 操作符，他明白的告诉程序："我要一个新的！不要旧的！"于是一个新的"Monday"Sting对象被创建在内存中。他们的值相同，但是位置不同，一个在池中游泳一个在岸边休息。哎呀，真是资源浪费，明明是一样的非要分开做什么呢？
4.再次更改程序：
public class TestString {
public static void main(String[] args) {
String s1 = "Monday";
String s2 = new String("Monday");
s2 = s2.intern();
if (s1 == s2)
{System.out.println("s1 == s2");}
else
{System.out.println("s1 != s2");}
if (s1.equals(s2)) {System.out.println("s1 equals s2");}
else{
System.out.println("s1 not equals s2");}
}
}
这次加入：s2 = s2.intern();
程序输出：
s1 == s2
s1 equals s2
原 来，（java.lang.String的intern()方法"abc".intern()方法的返回值还是字符串"abc"，表面上看起来好像这个方 法没什么用处。但实际上，它做了个小动作：检查字符串池里是否存在"abc"这么一个字符串，如果存在，就返回池里的字符串；如果不存在，该方法会 把"abc"添加到字符串池中，然后再返回它的引用。
）
如果方法中覆盖了超类的一个方法，子类中的访问级别就不允许低于超类中的访问权限这样就有可以确保任何可使用超类实例的方法都可以使用子类的实例
java中重载和覆盖(又称重写)的区别
重写方法的规则：
1、参数列表必须完全与被重写的方法相同，否则不能称其为重写而是重载。
2、返回的类型必须一直与被重写的方法的返回类型相同，否则不能称其为重写而是重载。
3、访问修饰符的限制一定要大于被重写方法的访问修饰符（public>protected>default>private）
4、重写方法一定不能抛出新的检查异常或者比被重写方法申明更加宽泛的检查型异常。例如：
父类的一个方法申明了一个检查异常IOException，在重写这个方法是就不能抛出Exception,只能抛出IOException的子类异常，可以抛出非检查异常。
而重载的规则：
1、必须具有不同的参数列表；
2、可以有不责骂的返回类型，只要参数列表不同就可以了；
3、可以有不同的访问修饰符；
4、可以抛出不同的异常；
无状态的对象无状态的对象，是一个对象，并且这个对象没有状态！
通常情况，几乎所有对象都有状态，
比如一个人，按照不同的情况有多种状态，比如高矮、胖瘦、黑白、高富帅穷矮挫。
比如一个杯子，玻璃的还是塑料，圆的还是方的。
你可以想一下，生活中哪些对象是无状态的？
抽象到程序设计中，无状态的对象，我们往往仅仅考虑对象的一个切面，
比如一个User，有多个属性，Name，Age等等，只要你认为这些属性的变化对User的唯一认定没有影响，那这些属性，就不会影响User的状态，意思是说这个User的状态我不关心这些属性，那这些属性的变更不能成为影响User的状态的必要因素。
比如User一个Age达到18岁了，我认为这个User的状态变化了，是成年人了，那么这个User是有状态的，状态就是是否成年，活着你认为Age多少岁无关紧要，那么这个User就是没有状态的。
对象状态的变化一般是由你关心的某属性变化引起的，无状态的对象一般是不可变对象，不可变对象是线程安全的。
static
-
static 修饰的变量称为类变量或全局变量或成员变量，在类被加载的时候成员变量即被初始化，与类关联，只要类存在，static变量就存在。
-
一个static变量单独划分一块存储空间，不与具体的对象绑定在一起，该存储空间被类的各个对象所共享。
-
也就是说当声明一个对象是，并不产生static变量的拷贝，而是该类所有的实例对象共用同一个static变量。
-
非static修饰的成员变量是在对象new出来的时候划分存储空间，是与具体的对象绑定的，该成员变量仅为当前对象所拥有的。
-
对象在引用成员变量是直接通过类名.变量名调用，对象在引用实例变量时只能通过对象名.变量名调用。
-
在类中调用成员变量时直接调用或者以类名.变量名方式调用，实例变量则用this或者直接调用。
http://wenjiesu.iteye.com/blog/799332
java里方法的内部类只能访问被final修饰的局部变量
| 在java中， 方法的内部类可以访问方法中的局部变量，但必须用final修饰才能访问。 原因： 一， 当方法被调用运行完毕之后，局部变量就已消亡了。但内部类对象可能还存在， 直到没有被引用时才会消亡。此时就会出现一种情况，就是内部类要访问一个不存在的局部变量。 二，解决这一问题的办法就是使用final修饰局部变量，通过将final局部变量"复制"一份, 复制品直接作为方法内部类中的数据成员，这事方法内部类访问的其实是这个局部变量的复制品！ 而且，由于被final修饰的变量赋值后不能再修改，所以就保证了复制品与原始变量的一致。 三，原因二的功能能实现的原因是：Java采用了一种copy local variable(复制局部变量)的方式来实现， 也就是说把定义为final的局部变量拷贝过来用，而引用的也可以拿过来用，只是不能重新赋值。 从而造成了可以access local variable(访问局部变量)的假象，而这个时候由于不能重新赋值， 所以一般不会造成不可预料的事情发生。 四， 使用final修饰符不仅会保持对象的引用不会改变, 而且编译器还会持续维护这个对象在回调方法中的生命周期. 所以这才是final变量和final参数的根本意义. |
Java内部类和静态类
http://www.360doc.com/content/13/0326/21/11482448_274116826.shtml
深入理解Java的接口和抽象类：抽象类是对一种事物的抽象，即对类抽象，而接口是对行为的抽象。
http://www.cnblogs.com/dolphin0520/p/3811437.html
http://www.cnblogs.com/xdp-gacl/p/3777987.html
http://blog.csdn.net/mageshuai/article/details/3849143
父类若没有不带参数的构造器，子类构造器必须显式调用超类其他的构造器
class Base{
Base(){
System.out.println("Base with no arg");
}
}
class Test extends Base{
Test(int v){
}
public static void main(String[] args) {
Test a = new Test(3);
}
}
输出
Base with no arg
这里子类里面没有显式调用父类的构造函数，但是父类的构造还是被调用了，说明Java加载类的时候，会加载父类的无参数的构造函数
class Base{
Base(int val){
System.out.println("Base int");
}
}
class Test extends Base{
Test(int v){
//如果这里不调用super(v) 是无法通过编译的
}
public static void main(String[] args) {
Test a = new Test(3);
}
}
子类构造器会默认调用 父类的无参构造器，如果父类没有无参构造器，则需在子类构造器的第一行显式地调用父类的其他构造器。
其次，从继承的思想来看，你继承一个类，就相当于扩展一个类，形成一个更为特殊的类，但经常，我们需要将子类向上转型为基类，以便使用或达到其他各种目的。
这时，如果你生成子类对象时没有调用父类的构造器，那么，我们在使用父类的一些成员变量的时候，就会报变量未初始化的错误。请记住，变量初始化总是在构造器调用之前完成！
immutable
http://my.oschina.net/jasonultimate/blog/166810?fromerr=gBqOfYjI
map的具体实现方式
HashMap 散列表 插入和查询的开销是固定的； 可以通过构造方法设置容量和负载因子，调整性能默认选择
LinkedHashMap 双向链表
取得元素的顺序是其插入次序，或者最近最少使用次序；插入时比HashMap略慢，但迭代时更快
TreeMap 红黑树 总是保证有序； 可以通过subMap()方法返回一个子树
WeakHashMap 弱键映射，允许释放映射所指向的对象
ConcurrentHashMap 线程安全，不涉及同步加锁
IdentityHashMap 用 == 代替 equals() 进行比较； 插入操作不会随着Map尺寸变大而明显变慢
HashMap详解
http://alex09.iteye.com/blog/539545
Java 集合实际上是多个引用变量所组成的集合，这些引用变量指向实际的 Java 对象。
原理细节：如果 HashMap 的每个 bucket 里只有一个 Entry 时，HashMap 可以根据索引、快速地取出该 bucket 里的 Entry；在发生“Hash 冲突”的情况下，单个 bucket 里存储的不是一个 Entry，而是一个 Entry 链，系统只能必须按顺序遍历每个 Entry，直到找到想搜索的 Entry 为止——如果恰好要搜索的 Entry 位于该 Entry 链的最末端（该 Entry 是最早放入该 bucket 中），那系统必须循环到最后才能找到该元素。
归纳起来简单地说，HashMap 在底层将 key-value 当成一个整体进行处理，这个整体就是一个 Entry 对象。HashMap 底层采用一个 Entry[] 数组来保存所有的 key-value 对，当需要存储一个 Entry 对象时，会根据 Hash 算法来决定其存储位置；当需要取出一个 Entry 时，也会根据 Hash 算法找到其存储位置，直接取出该 Entry。由此可见：HashMap 之所以能快速存、取它所包含的 Entry，完全类似于现实生活中母亲从小教我们的：不同的东西要放在不同的位置，需要时才能快速找到它。
当创建 HashMap 时，有一个默认的负载因子（load factor），其默认值为 0.75，这是时间和空间成本上一种折衷：增大负载因子可以减少 Hash 表（就是那个 Entry 数组）所占用的内存空间，但会增加查询数据的时间开销，而查询是最频繁的的操作（HashMap 的 get() 与 put() 方法都要用到查询）；减小负载因子会提高数据查询的性能，但会增加 Hash 表所占用的内存空间。
Java的HashMap和HashTable
http://www.cnblogs.com/dolphin0520/p/3920373.html 15L关于原子性的解释。
http://www.cnblogs.com/riskyer/p/3263032.html
native方法
http://blog.csdn.net/wike163/article/details/6635321