Java中Spring监听器的多种使用方式
作者：尤物程序猿
Java的spring事件监听模型还是很好用的。这里主要讲监听器的注解的使用方式。
最重要的有俩种注解
| 作用 | 适用场景 | ||
|---|---|---|---|
@EventListener | 标记方法为事件监听器 | 通用事件监听，*（非事务） | |
@TransactionalEventListener | 事务相关的事件监听 | 需要事务绑定的事件（事务） |
对于@EventListener，有三个参数
value、classes、condition
value和classes主要是指定相关事件的
condition是最常用的，使用Spring Expression Language (SpEL) 实现动态过滤。.
SpEL 表达式可以访问以下变量：
| 变量名 | 等价形式 | 说明 |
|---|---|---|
#root.event | event | 当前事件对象 |
#root.args | args | 方法参数数组 |
#a0, #p0 | args[0] | 第一个参数 |
#a1, #p1 | args[1] | 第二个参数 |
#orderEvent | 参数名为 orderEvent 的参数 |
也可以动态的注册一个spel函数
public static boolean calculateLength(int type, String article) {
//通过枚举解析type
//解析长度
}讲其注入到context中去
static class SpelFunctionRegister implements BeanFactoryAware, ApplicationContextAware {
@Override
public void setBeanFactory(BeanFactory beanFactory)
throws BeansException {
// 注册自定义函数
StandardEvaluationContext context =
((StandardEvaluationContext)
beanFactory.getBean(StandardEvaluationContext.class));
try {
// 注册一个计算评论内容的函数
context.registerFunction("calculateLength",
CustomSpELFunctions.class.getDeclaredMethod(
"calculateLength",
Integer.class, String.class));
} catch (NoSuchMethodException e) {
throw new RuntimeException("注册SpEL函数失败", e);
}
}
}@EventListener(condition =
"#calculatLenth(#event.commentType, #event.article)")
public void handleDiscountOrder(OrderEvent event) {
//符合评论类型、评论内容
}实际项目更常用的还是@TransactionalEventListener
它将事件监听与数据库事务的生命周期绑定，解决了“何时触发事件处理”这个关键问题。
退可当普通监听器使用，进可处理事务相关的监听，
定义了四个参数
1：phase（重要参数） ：以下四个策略
public enum TransactionPhase {
// 四个关键阶段
BEFORE_COMMIT, // 事务提交前
AFTER_COMMIT, // 事务提交后（默认）是最常用的
AFTER_ROLLBACK, // 事务回滚后
AFTER_COMPLETION // 事务完成后（无论成功失败）
}2：value() 就是指定监听具体的事件的，含义差不多
3：classes() 就是指定监听具体的事件的，含义差不多
4：condition() 与@EventListenner差不多一个东西
为什么说@EventListener在实际项目好像使用的更多一点，平时写代码不怎么使用这玩意呢
1：大部分表的update、delete、add肯定都会用事务进行包装，而对于这些增删改操作又会涉及到一系列的问题。比如清理缓存、一致性补偿、异步编排等等十分常见，将代码解耦合。对于实际项目的一个接口而言代码过长不利于扩展、理解以及数据的正确性
2：清理多节点本地缓存也十分常用，对于多节点的分布式系统而言，不可能都采用的远程缓存来做，必然有很多的本地缓存，或者是本地+远程远程来做的，如果涉及到缓存数据相关业务数据的变更，如果我只在当前节点进行清理缓存，那么其他节点就有可能有脏数据的问题，如果缓存时间还长，那线上环境的影响是很大的。比如清理所有节点的更新的业务缓存数据。对于采用了本地缓存的业务，在业务变更需要进行publis事件来清除缓存是最高效的。
到此这篇关于spring的监听器的几种使用方式的文章就介绍到这了,更多相关spring监听器内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！