5个最常问的几个Hibernate面试有关问题
5个最常问的几个Hibernate面试问题
不是吧 你这个是list和iterate的不同吧
在hibernate中，如果使用了延迟加载（比如常见的load方法），那么除访问主键以外的其它属性时，
就会去访问数据库（假设不考虑hibernate的一级缓存），此时session是不允许被关闭。
5个最常问的几个Hibernate面试问题，不一定你都能回答：
1.实体对象在Hibernate中如何进行状态迁移?
实体对象的状态及转化：
有了上面关于Hibernate缓存的知识，我们再来介绍实体对象的状态就非常容易理解了。
A:*态对象：(临时状态-transient)
当我们通过Java的new关键字来生成一个实体对象时，这时这个实体对象就处于*状态，如下：
Customer customer=new Customer(“zx”,27,images);
这时customer对象就处于*状态，为什么说customer对象处于*状态呢？这是因为，此时customer只是通过JVM获得了一块内存空间，还并没有通过Session对象的save()方法保存进数据库，因此也就还没有纳入Hibernate的缓存管理中，也就是说customer对象现在还*的游荡于Hibernate缓存管理之外。所以我们可以看出*对象最大的特点就是，在数据库中不存在一条与它对应的记录。
B:持久化对象: Persistent(持久态)
持久化对象就是已经被保存进数据库的实体对象，并且这个实体对象现在还处于Hibernate的缓存管理之中。这是对该实体对象的任何修改，都会在清理缓存时同步到数据库中。如下所示：
Customer customer=new Customer(“zx”,27,images);
tx=session.beginTransaction();
session.save(customer);
customer=(Customer)session.load(Customer.class,”1”);
customer.setAge(28);
tx.commit();
这时我们并没有显示调用session.update()方法来保存更新，但是对实体对象的修改还是会同步更新到数据库中，因为此时customer对象通过save方法保存进数据库后，已经是持久化对象了，然后通过load方法再次加载它，它仍然是持久化对象，所以它还处于Hibernate缓存的管理之中，这时当执行tx.commit()方法时，Hibernate会自动清理缓存，并且自动将持久化对象的属性变化同步到到数据库中。
C:游离对象： 游离状态---detached
当一个持久化对象，脱离开Hibernate的缓存管理后，它就处于游离状态，游离对象和*对象的最大区别在于，游离对象在数据库中可能还存在一条与它对应的记录，只是现在这个游离对象脱离了Hibernate的缓存管理，而*对象不会在数据库中出现与它对应的数据记录。如下所示：
Customer customer=new Customer(“zx”,27,images);
tx=session.beginTransaction();
session.save(customer);
customer=(Customer)session.load(Customer.class,”1”);
customer.setAge(28);
tx.commit();
session.close();
当session关闭后，customer对象就不处于Hibernate的缓存管理之中了，但是此时在数据库中还存在一条与customer对象对应的数据记录，所以此时customer对象处于游离态。
D:三种对象状态之间的转化：
这三种对象状态，是可以相互转化的，一个*对象可以通过session.save()方法或者session.saveorupdate()方法变成持久化对象，一个持久化对象可以通过session.flush()或者session.evict()方法，移出Hibernate缓存从而转化为游离对象，一个游离对象可以通过再次加载或者调用session.update()方法，再次恢复为持久化对象，也可以通过调用session.delete()方法变成*对象，并且删除数据库中对应的数据记录。
示例程序：
Configuration cfg = new Configuration();
SessionFactory sf=cfg.configure().buildSessionFactory();
Customer customer=new Customer(“zx”,27,images);//customer对象处于*状态
Session session=sf.openSession();
Transaction tx=session.beginTransaction();
session.save(customer);//保存后customer对象处于持久化状态
session.flush();//清空缓存后customer对象处于游离状态
tx.commit();
session.close();
Session session2=sf.openSession();
Transaction tx2=session2.beginTransaction();
session2.update(customer);//通过调用update()方法将游离状态的customer对象，再次转化成持久化状态
session2.delete(customer);//调用delete()方法后，当清空缓存时，会将customer对象移出缓存，同时会在数据库中生成delete事务，来删除customer对象对应的数据记录
tx.commit();
session.close();
2.何谓Hibernate的N+1问题，如何解决？
Hibernate n+1问题
默认情况下，query.iterate查询时候，有可以能出现N+1问题
具体来说当你查询时首先hibernate会发出一天查询所有主键的sql语句，然后跟新缓存。N就是指首先hiberante会到缓存中查询，如果缓存中不存在与之匹配的数据，再会发出sql查询。
主要的原因是：默认情况下iterate利用缓存数据来查询，当缓存为空会多查询一次，把ID加进来。
在Session的缓存中存放的是相互关联的对象图。默认情况下，当Hibernate从数据库中加载Customer对象时，会同时加载所有关联的 Order对象。以Customer和Order类为例，假定ORDERS表的CUSTOMER_ID外键允许为null
以下Session的find()方法用于到数据库中检索所有的Customer对象：
List customerLists=session.find("from Customer as c");
运行以上find()方法时，Hibernate将先查询CUSTOMERS表中所有的记录，然后根据每条记录的ID，到ORDERS表中查询有参照关系的记录，Hibernate将依次执行以下select语句：
select * from CUSTOMERS;
select * from ORDERS where CUSTOMER_ID=1;
select * from ORDERS where CUSTOMER_ID=2;
select * from ORDERS where CUSTOMER_ID=3;
select * from ORDERS where CUSTOMER_ID=4;
通过以上5条select语句，Hibernate最后加载了4个Customer对象和5个Order对象，在内存中形成了一幅关联的对象图.
Hibernate在检索与Customer关联的Order对象时，使用了默认的立即检索策略。这种检索策略存在两大不足：
（1） select语句的数目太多，需要频繁的访问数据库，会影响检索性能。如果需要查询n个Customer对象，那么必须执行n+1次select查询语句。这就是经典的n+1次select查询问题。这种检索策略没有利用SQL的连接查询功能，例如以上5条select语句完全可以通过以下1条 select语句来完成：
select * from CUSTOMERS left outer join ORDERS
on CUSTOMERS.ID=ORDERS.CUSTOMER_ID
以上select语句使用了SQL的左外连接查询功能，能够在一条select语句中查询出CUSTOMERS表的所有记录，以及匹配的ORDERS表的记录。
（2）在应用逻辑只需要访问Customer对象，而不需要访问Order对象的场合，加载Order对象完全是多余的操作，这些多余的Order对象白白浪费了许多内存空间。
为了解决以上问题，Hibernate提供了其他两种检索策略：延迟检索策略和迫切左外连接检索策略。延迟检索策略能避免多余加载应用程序不需要访问的关联对象，迫切左外连接检索策略则充分利用了SQL的外连接查询功能，能够减少select语句的数目。
对数据库访问还是必须考虑性能问题的， 在设定了1 对多这种关系之后， 查询就会出现传说中的n +1 问题。
1 ）1 对多，在1 方，查找得到了n 个对象， 那么又需要将n 个对象关联的集合取出，于是本来的一条sql查询变成了n +1 条
2）多对1 ，在多方，查询得到了m个对象，那么也会将m个对象对应的1 方的对象取出， 也变成了m+1
怎么解决n +1 问题？
1 ）lazy=true， hibernate3开始已经默认是lazy=true了；lazy=true时不会立刻查询关联对象，只有当需要关联对象（访问其属性，非id字段）时才会发生查询动作。
2）二级缓存， 在对象更新，删除，添加相对于查询要少得多时， 二级缓存的应用将不怕n +1 问题，因为即使第一次查询很慢，之后直接缓存命中也是很快的。
不同解决方法，不同的思路，第二条却刚好又利用了n +1 。
3) 当然你也可以设定fetch=join(annotation : @ManyToOne() @Fetch(FetchMode.JOIN))
3.Hibernate延迟加载的机制是什么，如何工作？
4.Hibernate级联保存要如何做？
5.Hibernate的二级缓存和一级缓存有什么区别？
不是吧 你这个是list和iterate的不同吧
在hibernate中，如果使用了延迟加载（比如常见的load方法），那么除访问主键以外的其它属性时，
就会去访问数据库（假设不考虑hibernate的一级缓存），此时session是不允许被关闭。
5个最常问的几个Hibernate面试问题，不一定你都能回答：
1.实体对象在Hibernate中如何进行状态迁移?
实体对象的状态及转化：
有了上面关于Hibernate缓存的知识，我们再来介绍实体对象的状态就非常容易理解了。
A:*态对象：(临时状态-transient)
当我们通过Java的new关键字来生成一个实体对象时，这时这个实体对象就处于*状态，如下：
Customer customer=new Customer(“zx”,27,images);
这时customer对象就处于*状态，为什么说customer对象处于*状态呢？这是因为，此时customer只是通过JVM获得了一块内存空间，还并没有通过Session对象的save()方法保存进数据库，因此也就还没有纳入Hibernate的缓存管理中，也就是说customer对象现在还*的游荡于Hibernate缓存管理之外。所以我们可以看出*对象最大的特点就是，在数据库中不存在一条与它对应的记录。
B:持久化对象: Persistent(持久态)
持久化对象就是已经被保存进数据库的实体对象，并且这个实体对象现在还处于Hibernate的缓存管理之中。这是对该实体对象的任何修改，都会在清理缓存时同步到数据库中。如下所示：
Customer customer=new Customer(“zx”,27,images);
tx=session.beginTransaction();
session.save(customer);
customer=(Customer)session.load(Customer.class,”1”);
customer.setAge(28);
tx.commit();
这时我们并没有显示调用session.update()方法来保存更新，但是对实体对象的修改还是会同步更新到数据库中，因为此时customer对象通过save方法保存进数据库后，已经是持久化对象了，然后通过load方法再次加载它，它仍然是持久化对象，所以它还处于Hibernate缓存的管理之中，这时当执行tx.commit()方法时，Hibernate会自动清理缓存，并且自动将持久化对象的属性变化同步到到数据库中。
C:游离对象： 游离状态---detached
当一个持久化对象，脱离开Hibernate的缓存管理后，它就处于游离状态，游离对象和*对象的最大区别在于，游离对象在数据库中可能还存在一条与它对应的记录，只是现在这个游离对象脱离了Hibernate的缓存管理，而*对象不会在数据库中出现与它对应的数据记录。如下所示：
Customer customer=new Customer(“zx”,27,images);
tx=session.beginTransaction();
session.save(customer);
customer=(Customer)session.load(Customer.class,”1”);
customer.setAge(28);
tx.commit();
session.close();
当session关闭后，customer对象就不处于Hibernate的缓存管理之中了，但是此时在数据库中还存在一条与customer对象对应的数据记录，所以此时customer对象处于游离态。
D:三种对象状态之间的转化：
这三种对象状态，是可以相互转化的，一个*对象可以通过session.save()方法或者session.saveorupdate()方法变成持久化对象，一个持久化对象可以通过session.flush()或者session.evict()方法，移出Hibernate缓存从而转化为游离对象，一个游离对象可以通过再次加载或者调用session.update()方法，再次恢复为持久化对象，也可以通过调用session.delete()方法变成*对象，并且删除数据库中对应的数据记录。
示例程序：
Configuration cfg = new Configuration();
SessionFactory sf=cfg.configure().buildSessionFactory();
Customer customer=new Customer(“zx”,27,images);//customer对象处于*状态
Session session=sf.openSession();
Transaction tx=session.beginTransaction();
session.save(customer);//保存后customer对象处于持久化状态
session.flush();//清空缓存后customer对象处于游离状态
tx.commit();
session.close();
Session session2=sf.openSession();
Transaction tx2=session2.beginTransaction();
session2.update(customer);//通过调用update()方法将游离状态的customer对象，再次转化成持久化状态
session2.delete(customer);//调用delete()方法后，当清空缓存时，会将customer对象移出缓存，同时会在数据库中生成delete事务，来删除customer对象对应的数据记录
tx.commit();
session.close();
2.何谓Hibernate的N+1问题，如何解决？
Hibernate n+1问题
默认情况下，query.iterate查询时候，有可以能出现N+1问题
具体来说当你查询时首先hibernate会发出一天查询所有主键的sql语句，然后跟新缓存。N就是指首先hiberante会到缓存中查询，如果缓存中不存在与之匹配的数据，再会发出sql查询。
主要的原因是：默认情况下iterate利用缓存数据来查询，当缓存为空会多查询一次，把ID加进来。
在Session的缓存中存放的是相互关联的对象图。默认情况下，当Hibernate从数据库中加载Customer对象时，会同时加载所有关联的 Order对象。以Customer和Order类为例，假定ORDERS表的CUSTOMER_ID外键允许为null
以下Session的find()方法用于到数据库中检索所有的Customer对象：
List customerLists=session.find("from Customer as c");
运行以上find()方法时，Hibernate将先查询CUSTOMERS表中所有的记录，然后根据每条记录的ID，到ORDERS表中查询有参照关系的记录，Hibernate将依次执行以下select语句：
select * from CUSTOMERS;
select * from ORDERS where CUSTOMER_ID=1;
select * from ORDERS where CUSTOMER_ID=2;
select * from ORDERS where CUSTOMER_ID=3;
select * from ORDERS where CUSTOMER_ID=4;
通过以上5条select语句，Hibernate最后加载了4个Customer对象和5个Order对象，在内存中形成了一幅关联的对象图.
Hibernate在检索与Customer关联的Order对象时，使用了默认的立即检索策略。这种检索策略存在两大不足：
（1） select语句的数目太多，需要频繁的访问数据库，会影响检索性能。如果需要查询n个Customer对象，那么必须执行n+1次select查询语句。这就是经典的n+1次select查询问题。这种检索策略没有利用SQL的连接查询功能，例如以上5条select语句完全可以通过以下1条 select语句来完成：
select * from CUSTOMERS left outer join ORDERS
on CUSTOMERS.ID=ORDERS.CUSTOMER_ID
以上select语句使用了SQL的左外连接查询功能，能够在一条select语句中查询出CUSTOMERS表的所有记录，以及匹配的ORDERS表的记录。
（2）在应用逻辑只需要访问Customer对象，而不需要访问Order对象的场合，加载Order对象完全是多余的操作，这些多余的Order对象白白浪费了许多内存空间。
为了解决以上问题，Hibernate提供了其他两种检索策略：延迟检索策略和迫切左外连接检索策略。延迟检索策略能避免多余加载应用程序不需要访问的关联对象，迫切左外连接检索策略则充分利用了SQL的外连接查询功能，能够减少select语句的数目。
对数据库访问还是必须考虑性能问题的， 在设定了1 对多这种关系之后， 查询就会出现传说中的n +1 问题。
1 ）1 对多，在1 方，查找得到了n 个对象， 那么又需要将n 个对象关联的集合取出，于是本来的一条sql查询变成了n +1 条
2）多对1 ，在多方，查询得到了m个对象，那么也会将m个对象对应的1 方的对象取出， 也变成了m+1
怎么解决n +1 问题？
1 ）lazy=true， hibernate3开始已经默认是lazy=true了；lazy=true时不会立刻查询关联对象，只有当需要关联对象（访问其属性，非id字段）时才会发生查询动作。
2）二级缓存， 在对象更新，删除，添加相对于查询要少得多时， 二级缓存的应用将不怕n +1 问题，因为即使第一次查询很慢，之后直接缓存命中也是很快的。
不同解决方法，不同的思路，第二条却刚好又利用了n +1 。
3) 当然你也可以设定fetch=join(annotation : @ManyToOne() @Fetch(FetchMode.JOIN))
3.Hibernate延迟加载的机制是什么，如何工作？
4.Hibernate级联保存要如何做？
5.Hibernate的二级缓存和一级缓存有什么区别？