面试问题整理f1

Spring的作用。


Spring的Ioc（控制反转和依赖注入）
     控制反转：就是由容器控制程序之间的（依赖）关系，而非传统实现中，由程序代码直
接操控。
     依赖注入：组件之间的依赖关系由容器在运行期决定 ，由容器动态的将某种依赖关系注
入到组件之中。


Spring容器控制所有Action对象和
业务逻辑类的生命周期，由与上层不再控制下层的生命周期，层与层之间实现了完全脱耦，
使程序运行起来效率更高，维护起来也方便。


使用Spring的第二个好处（AOP应用）
在以往的JDBCTemplate中事务提交成功，异常处理都是通过Try/Catch 来完成，而在
Spring中。Spring容器集成了TransactionTemplate，她封装了所有对事务处理的功能，
包括异常时事务回滚，操作成功时数据提交等复杂业务功能。这都是由Spring容器来管理，
大大减少了程序员的代码量，也对事务有了很好的管理控制。Hibernate中也有对事务的管
理，hibernate中事务管理是通过SessionFactory创建和维护Session来完成。而Spring对
SessionFactory配置也进行了整合，不需要在通过hibernate.cfg.xml来对
SessionaFactory进行设定。这样的话就可以很好的利用Sping对事务管理强大功能。避免
了每次对数据操作都要现获得Session实例来启动事务/提交/回滚事务还有繁琐的
Try/Catch操作。这些也就是Spring中的AOP（面向切面编程）机制很好的应用。一方面使
开发业务逻辑更清晰、专业分工更加容易进行。另一方面就是应用Spirng  AOP隔离降低了
程序的耦合性使我们可以在不同的应用中将各个切面结合起来使用大大提高了代码重用度。


Integer与int的区别(为什么要有包装类，包装类有什么好处)


Collection与Collections的区别


Collection 和 Collections的区别。 
Collections是个java.util下的类，它包含有各种有关集合操作的静态方法。 


Collection是个java.util下的接口，它是各种集合结构的父接口。 


List, Set, Map是否继承自Collection接口? List，Set是  Map不是 


ArrayList和Vector的区别。 


一.同步性:Vector是线程安全的，也就是说是同步的，而ArrayList是线程序不安全的，不是同步的 
二.数据增长:当需要增长时,Vector默认增长为原来一培，而ArrayList却是原来的一半 


HashMap和Hashtable的区别 


一.历史原因:Hashtable是基于陈旧的Dictionary类的，HashMap是Java 1.2引进的Map接口的一个实现 


二.同步性:Hashtable是线程安全的，也就是说是同步的，而HashMap是线程序不安全的，不是同步的 


三.值：只有HashMap可以让你将空值作为一个表的条目的key或value 


HashMap与LinkedMap的区别


HashMap,LinkedHashMap,TreeMap都属于Map
Map 主要用于存储键(key)值(value)对，根据键得到值，因此键不允许键重复,但允许值重复。
 
HashMap
是一个最常用的Map,它根据键的HashCode 值存储数据,根据键可以直接获取它的值，具有很快的访问速度。HashMap最多只允许一条记录的键为Null;允许多条记录的值为 Null;HashMap不支持线程的同步，即任一时刻可以有多个线程同时写HashMap;可能会导致数据的不一致。如果需要同步，可以用 Collections的synchronizedMap方法使HashMap具有同步的能力。


LinkedHashMap
LinkedHashMap也是一个HashMap,但是内部维持了一个双向链表,可以保持顺序






一张表死锁，能向另外一张与该表连接的表插入数据嘛？






接口可以继承接口嘛？


1.接口可以继承接口..但是要使用extends~而不是用implements
如:interface a{}
interface b extends a{}


2.抽象类可以实现接口..
比如java.util中的AbstractCollection类就是实现的Collection接口


3.抽象类可以继承实体类




死锁产生的原因及四个必要条件


产生死锁的原因主要是：
（1） 因为系统资源不足。
（2） 进程运行推进的顺序不合适。
（3） 资源分配不当等。
如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则
就会因争夺有限的资源而陷入死锁。其次，进程运行推进顺序与速度不同，也可能产生死锁。
产生死锁的四个必要条件：
（1） 互斥条件：一个资源每次只能被一个进程使用。
（2） 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
（3） 不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。
（4） 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之
一不满足，就不会发生死锁。
死锁的解除与预防：
理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和
解除死锁。所以，在系统设计、进程调度等方面注意如何不让这四个必要条件成立，如何确
定资源的合理分配算法，避免进程永久占据系统资源。此外，也要防止进程在处于等待状态
的情况下占用资源。因此，对资源的分配要给予合理的规划。
顶




范式：英文名称是 Normal Form，它是英国人 E.F.Codd（关系数据库的老祖宗）在上个世纪70年代提出关系数据库模型后总结出来的，范式是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法。目前有迹可寻的共有8种范式，依次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。通常所用到的只是前三个范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。下面就简单介绍下这三个范式。 
◆ 第一范式（1NF）：强调的是列的原子性，即列不能够再分成其他几列。 
考虑这样一个表：【联系人】（姓名，性别，电话） 
如果在实际场景中，一个联系人有家庭电话和公司电话，那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列（电话）拆分，即：【联系人】（姓名，性别，家庭电话，公司电话）。1NF 很好辨别，但是 2NF 和 3NF 就容易搞混淆。 
◆ 第二范式（2NF）：首先是 1NF，另外包含两部分内容，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。 
考虑一个订单明细表：【OrderDetail】（OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName）。 
因为我们知道在一个订单中可以订购多种产品，所以单单一个 OrderID 是不足以成为主键的，主键应该是（OrderID，ProductID）。显而易见 Discount（折扣），Quantity（数量）完全依赖（取决）于主键（OderID，ProductID），而 UnitPrice，ProductName 只依赖于 ProductID。所以 OrderDetail 表不符合 2NF。不符合 2NF 的设计容易产生冗余数据。 
可以把【OrderDetail】表拆分为【OrderDetail】（OrderID，ProductID，Discount，Quantity）和【Product】（ProductID，UnitPrice，ProductName）来消除原订单表中UnitPrice，ProductName多次重复的情况。 
◆ 第三范式（3NF）：首先是 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。 
考虑一个订单表【Order】（OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity）主键是（OrderID）。 
其中 OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity 等非主键列都完全依赖于主键（OrderID），所以符合 2NF。不过问题是 CustomerName，CustomerAddr，CustomerCity 直接依赖的是 CustomerID（非主键列），而不是直接依赖于主键，它是通过传递才依赖于主键，所以不符合 3NF。 
通过拆分【Order】为【Order】（OrderID，OrderDate，CustomerID）和【Customer】（CustomerID，CustomerName，CustomerAddr，CustomerCity）从而达到 3NF。 
第二范式（2NF）和第三范式（3NF）的概念很容易混淆，区分它们的关键点在于，2NF：非主键列是否完全依赖于主键，还是依赖于主键的一部分；3NF：非主键列是直接依赖于主键，还是直接依赖于非主键列。