java 复习001
比较随意的记录下我的java复习笔记
ArrayList 内存扩展方法
- 分配一片更大的内存空间，复制原有的数据到新的内存中，让引用指向新的内存地址
ArrayList在内存不够时默认是扩展为1.5倍 + 1个
ArrayList,LinkedList,Vector 区别
- Vector内存扩展和ArrayList一样，不过Vector是默认扩展为2倍
Vector支持线程的同步，因此牺牲了访问性能
ArrayList，Vector都是使用数组实现，插入删除效率低
LinkedList是链表实现，插入删除效率高，但遍历和随机访问速率低
LinkedList提供操作链头和链尾的方法，可以轻松实现栈和队列
HashMap和HashTable的区别
HashMap实现详见：vblog-HashMap
Hashtable 类似于 HashMap，但是不允许 null 键和 null 值。它也比 HashMap 慢，因为它是同步的。
附张简单的java集合类关系图
java泛型和c++的区别
- c++叫函数模板（template）,在编译期间会转换为模板类的目标代码
java在编译期间不会转换成泛型类的目标代码，而是生成
Object的目标代码，然后在Object前加必要的类型转换代码java的泛型是伪泛型，因为只是在编译期间添加了类型转换代码，和自己手动添加没有任何区别，只能起更直观的类型控制作用，没有像c++那样提高效率
而且这种类型转换导致java的泛型不能是基础类型(如:int)，而c++就没有这个限制了
java内存溢出问题
- 数据库查询条目太多，Hiberate session处理数据时，同个session会缓存所有的条目，导致内存不够溢出了
同一个session进行分页查询，注意session.clear()
特别注意资源调用时注意关闭，容易导致内存泄漏
链条编程
方法返回和本身类同样的对象
使用效果: chain.add("1").add("2")
filter(过滤器)
一个统一的Filter接口
一个doFilter()方法
一个主FilterChain，可能嵌入很多子FilterChain
实现了Filter接口
多个过滤类的集合(ArrayList)
也实现了Filter接口
处理程序的process方法有待处理的参数和主FilterChain
动态代理(dynamic proxy)->interaptor(拦截器)
情景：当你想给一个已经存在且没法改源代码的类，在类的某个方法前后加上处理代码（如：计算运行时间代码）
实现方法（面向切面编程AOP）：
- 使用
extends继承，然后重写方法，在父类方法的前后加上处理代码
不够灵活，因为继承只能是一个确定的类，不能多态，也就不容易嵌套代理
使用implements实现类的父类的接口，并且保存一个父类的引用（聚合），然后重写方法，在父类方法的前后加上处理代码
很灵活，实现一个统一的接口能代理所有实现了这个接口的类对象，可以很容易嵌套代理
真正体现了多态之强大了
根据DynamicHandlerInterface和ObjectInterface动态得到一个代理类
底层实现有两种方法：jdk动态代理和cglib动态代理
两者区别：jdk动态代理是由java内部的反射机制来实现的，cglib动态代理底层则是借助asm来实现的。总的来说，反射机制在生成类的过程中比较高效，而asm在生成类之后的相关执行过程中比较高效（可以通过将asm生成的类进行缓存，这样解决asm生成类过程低效问题）。还有一点必须注意：jdk动态代理的应用前提，必须是目标类基于统一的接口。如果没有上述前提，jdk动态代理不能应用。由此可以看出，jdk动态代理有一定的局限性，cglib这种第三方类库实现的动态代理应用更加广泛，且在效率上更有优势。csdn
工厂模式(Factory)
情景：手机切换主题
简介：能用来创建一系列实现了相同接口的对象，如：多样的主题类
可参考：iteye
单例模式
简介：一个类只有一个对象
必要条件
- 私有的构造方法
static的自身引用
static的
getInstance()方法Hibernate
对象状态转换图
1+N问题
问题简述
- 在*@ManyToOne*关系中，给Many的
FetchType设为EAGER在查询这个类对象时，Hibernate会先发送一条Select语句查询这个类对象，接着发送N条Select语句来查询与之相关的类对象
解决方法
- 将这个类的
FetchType设置为LAZY；与之相关的类对象查询语句将按需而发在这个类定义前加上
@BatchSize(批处理)；设置批数据大小，也就是一次操作对象的数目，这样可以成倍减少查询语句的条数使用HQL语句
join fetch，例如：from Topic t left join fetch t.category c；合并查询，一个对象将只发一条查询语句缓存
一级缓存：session级别的缓存
二级缓存：SessionFactory级别的缓存，跨session存在
- 经常访问
改动不大
数量有限
事务ACID
Atomic(原子性)：事务不可分
Consistency(一致性)：数据一致，必须满足必要的约束，如：约束条件（a-b=1）,如果a=2,那么b必须为1
Itegrity(完整性)：事务之间不会交叉执行，防止数据不一致
Durability(持久性)：事务运行成功后数据将持久到数据库，不会出现意外的回滚
事务并发问题
- 脏读：A事务读到B事务没有提交的数据（B可能出现回滚，导致数据不一致）
不可重复读：A有两次读数据，第一次在B提交数据之前，第二次在B提交事务之后，出现两次读取的数据不一致
幻读：和不可重复读一样，只是突出A在查询时的数据不一致
第一类丢失更新：A读取数据然后进行修改，B在A回滚数据之前提交了一次修改过的数据，最后A回滚到最开始的数据，丢失了B的操作
第二类丢失更新：A读取数据然后进行修改，在A提交数据之前，B先于A提交了一次修改过的数据，导致B提交的数据丢失了
悲观锁：基于数据库的加锁实现
思想：程序悲观的认为在它操作期间肯定会有人修改数据，所以先给数据库加把锁，不让其他人操作数据库，直到自己处理完成时才解锁
乐观锁：程序控制（不加锁，效率稍高）
思想：程序乐观的认为在它操作期间不会有人修改数据，所以先大胆的操作，只是在存数据时检查下是否有人修改过数据
具体实现：给数据库表中加上version字段，每次update都给version加一，在update之前先检查version值是否一致，不一致再重新执行事物，或者采取其他操作
hibernate与ibatis的对比：
- ibatis非常简单易学，hibernate相对较复杂，门槛较高。
二者都是比较优秀的开源产品
当系统属于二次开发,无法对数据库结构做到控制和修改,那ibatis的灵活性将比hibernate更适合
系统数据处理量巨大，性能要求极为苛刻，这往往意味着我们必须通过经过高度优化的sql语句（或存储过程）才能达到系统性能设计指标。在这种情况下ibatis会有更好的可控性和表现。
ibatis需要手写sql语句，也可以生成一部分，hibernate则基本上可以自动生成，偶尔会写一些hql。同样的需求,ibatis的工作量比hibernate要大很多。类似的，如果涉及到数据库字段的修改，hibernate修改的地方很少，而ibatis要把那些sql mapping的地方一一修改。
以数据库字段一一对应映射得到的po和hibernte这种对象化映射得到的po是截然不同的，本质区别在于这种po是扁平化的，不像hibernate映射的po是可以表达立体的对象继承，聚合等等关系的，这将会直接影响到你的整个软件系统的设计思路。
hibernate现在已经是主流o/r mapping框架，从文档的丰富性，产品的完善性，版本的开发速度都要强于ibatis。
参考至:http://blog.csdn.net/cdh1213/article/details/5967405
