Nutz->>反复新建ioc容器的后果
Nutz--->>反复新建ioc容器的后果
问题：
public class DaoZ {
public static Dao dao() { // 每当需要使用dao的时候就取一次
Ioc ioc = new NutIoc(new JsonLoader("dao.js"));
return ioc.get(Dao.class);
}
}
----------------------------------------------------------------------------
Wedal解析：
注意, java.sql.DataSource只是个接口.但下面讨论的DataSource均指代数据库连接池实现.
根本原因在于: Nutz的Ioc容器不是全局的,一旦没有被引用,就随时被GC.
题目中的NutIoc实例,在方法返回之后,处于无引用的状态, 即满足了GC的条件,随时会被GC.
题目中默认为2个基本ioc对象, DataSource和Dao, 其中Dao默认指代NutDao
NutIoc被gc时,会触发depose事件, 从而调用各ioc对象的depose/close方法
一般来说DataSource都会配置成depose事件触发close方法,即关闭连接池. 这样就导致DataSource对象处于关闭状态, 而NutDao的数据库连接均由DataSource提供, 直接导致NutDao实例在操作任意数据库方法时报错.
注意, GC的时机是几乎不可控,不可预测的, 这就意味着上述的ioc容器被gc, depose方法被调用,DataSource被关闭的时机也是不可控及不可预测的. 这会导致程序有时候是好的(GC在Dao方法执行完成之后),有时候会挂的(GC在Dao执行完成之前)
错误的解决思路:
1. 去掉depose事件. 首先是连接池都有初始大小和最小活跃数,这意味着DataSource被gc前总持有那么几个数据库连接. 并发上去了,gc来不及, 很快就数据库连接耗尽.
2. 那,去掉depose事件,连接池初始化大小和最小活跃数都设置为0呢. 初始化大小为0, 但你总会使用一次NutDao的方法吧, 那么就建立了一个连接, 然后最小活跃数是0, 将连接数从1降为0那么, 总有那么一个时间差,然后, 呵呵, 一个坑就摆在那了, 哪天碰巧没能快速关闭,也没被gc, 爆数据库连接数
3. 好吧,那我不用连接池,可以了吧? 可以,性能掉渣
解决方法:
1 在Mvc中, 你几乎100%会用到@IocBy, 也就是NutMvc来持有ioc, 那么你就不别自行new NutIoc了. 在Setup接口中,你可以通过config.getIoc()来获取Ioc容器(常见于启动时的初始化,加载全局变量,计划任务什么的), 在任何不可能直接得到Ioc容器的地方, 通过 Mvcs.ctx().getDefaultIoc() 获取 .注意, Mvcs.ctx()总是非常规方法.
2 非Mvc环境, 应使用一个工具类管理, 而且必须持有Ioc容器
3
public class DaoZ { // 供参考
private static Ioc ioc; // 静态属性,确保了Ioc容器不会被gc
public static synchronized Ioc ioc() { // 同步,用你喜欢的方法就好啦
if (ioc == null) {
try {
ioc = new NutIoc(new ComboIocLoader("*js","ioc/", "*annotation", "net.wendal.iot"));
}
catch (ClassNotFoundException e) {
throw Lang.warp(e);
}
}
return ioc;
}
public static Dao dao() {
return ioc.get(Dao.class);
}
}
问题：
public class DaoZ {
public static Dao dao() { // 每当需要使用dao的时候就取一次
Ioc ioc = new NutIoc(new JsonLoader("dao.js"));
return ioc.get(Dao.class);
}
}
----------------------------------------------------------------------------
Wedal解析：
注意, java.sql.DataSource只是个接口.但下面讨论的DataSource均指代数据库连接池实现.
根本原因在于: Nutz的Ioc容器不是全局的,一旦没有被引用,就随时被GC.
题目中的NutIoc实例,在方法返回之后,处于无引用的状态, 即满足了GC的条件,随时会被GC.
题目中默认为2个基本ioc对象, DataSource和Dao, 其中Dao默认指代NutDao
NutIoc被gc时,会触发depose事件, 从而调用各ioc对象的depose/close方法
一般来说DataSource都会配置成depose事件触发close方法,即关闭连接池. 这样就导致DataSource对象处于关闭状态, 而NutDao的数据库连接均由DataSource提供, 直接导致NutDao实例在操作任意数据库方法时报错.
注意, GC的时机是几乎不可控,不可预测的, 这就意味着上述的ioc容器被gc, depose方法被调用,DataSource被关闭的时机也是不可控及不可预测的. 这会导致程序有时候是好的(GC在Dao方法执行完成之后),有时候会挂的(GC在Dao执行完成之前)
错误的解决思路:
1. 去掉depose事件. 首先是连接池都有初始大小和最小活跃数,这意味着DataSource被gc前总持有那么几个数据库连接. 并发上去了,gc来不及, 很快就数据库连接耗尽.
2. 那,去掉depose事件,连接池初始化大小和最小活跃数都设置为0呢. 初始化大小为0, 但你总会使用一次NutDao的方法吧, 那么就建立了一个连接, 然后最小活跃数是0, 将连接数从1降为0那么, 总有那么一个时间差,然后, 呵呵, 一个坑就摆在那了, 哪天碰巧没能快速关闭,也没被gc, 爆数据库连接数
3. 好吧,那我不用连接池,可以了吧? 可以,性能掉渣
解决方法:
1 在Mvc中, 你几乎100%会用到@IocBy, 也就是NutMvc来持有ioc, 那么你就不别自行new NutIoc了. 在Setup接口中,你可以通过config.getIoc()来获取Ioc容器(常见于启动时的初始化,加载全局变量,计划任务什么的), 在任何不可能直接得到Ioc容器的地方, 通过 Mvcs.ctx().getDefaultIoc() 获取 .注意, Mvcs.ctx()总是非常规方法.
2 非Mvc环境, 应使用一个工具类管理, 而且必须持有Ioc容器
3
public class DaoZ { // 供参考
private static Ioc ioc; // 静态属性,确保了Ioc容器不会被gc
public static synchronized Ioc ioc() { // 同步,用你喜欢的方法就好啦
if (ioc == null) {
try {
ioc = new NutIoc(new ComboIocLoader("*js","ioc/", "*annotation", "net.wendal.iot"));
}
catch (ClassNotFoundException e) {
throw Lang.warp(e);
}
}
return ioc;
}
public static Dao dao() {
return ioc.get(Dao.class);
}
}