@Lazy 注解为啥就能破解死循环？-低调大师

@Lazy 注解为啥就能破解死循环？

2023-07-20 323

以下内容基于 Spring6.0.4。

上篇文章松哥和大家聊了在 Spring 中并非所有的循环依赖都可以被解决，有一些循环依赖默认情况下 Spring 也是完全无法解决的。不熟悉的小伙伴可以先看看上篇文章。

以上篇文章第一小节的案例为例，在构造方法中互相注入对方的 Bean，此时完全就是一个死循环呀，对于这种死循环，难道真的有办法解决？

Spring 里边提供了办法来解决，但是似乎又没有解决，为什么这么说，看完本文你就明白了。

1. @Lazy

如本文题目所示，上篇文章涉及到的三种无法自动解决的循环依赖，都可以通过添加 @Lazy 注解来解决。

如果是构造器注入，如下：

@Service
public class AService {

    BService bService;

    @Lazy
    public AService(BService bService) {
        this.bService = bService;
    }

    public BService getbService() {
        return bService;
    }
}
@Service
public class BService {
    AService aService;
    
    @Lazy
    public BService(AService aService) {
        this.aService = aService;
    }

    public AService getaService() {
        return aService;
    }
}

@Lazy 注解可以添加在 AService 或者 BService 的构造方法上，也可以都添加上。

添加上之后，我们再去启动项目，就不会报错了。这样看起来问题解决了，但是其实还是差点意思，小伙伴们看一下我的启动代码：

ClassPathXmlApplicationContext ctx = new ClassPathXmlApplicationContext("aop.xml");
AService aService = ctx.getBean(AService.class);
BService bService = ctx.getBean(BService.class);
System.out.println("aService.getClass() = " + aService.getClass());
System.out.println("bService.getClass() = " + bService.getClass());
System.out.println("aService.getbService().getClass() = " + aService.getbService().getClass());
System.out.println("bService.getaService().getClass() = " + bService.getaService().getClass());

最终打印结果如下：

小伙伴们看到，我们从 AService 和 BService 中获取到的 Bean 都是正常的未被代理的对象，事实上我们的原始代码确实也没有需要代理的地方。但是，AService 中的 BService 以及 BService 中的 AService 却都是代理对象，按理说 AService 中的 BService 应该和我们从 Spring 容器中获取到的 BService 一致，BService 中的 AService 也应该和 Spring 容器中获取到的 AService 一致，但实际上，两者却并不相同。

不过这样也好懂了，为什么 Spring 能把一个死结给解开，就是因为 AService 和 BService 各自注入的 Bean 都不是原始的 Bean，都是一个代理的 Bean，AService 中注入的 BService 是一个代理对象，同理，BService 中注入的 AService 也是一个代理对象。

这也是为什么我一开始说这个问题 Spring 解决了又没解决。

其实，这就是 @Lazy 这个注解的工作原理，看名字，加了该注解的对象会被延迟加载，实际上被该注解标记的对象，会自动生成一个代理对象。

上篇文章中提到的另外两个问题，也可以通过 @Lazy 注解来解决，代码如下：

@Service
@Scope("prototype")
public class AService {
    @Lazy
    @Autowired
    BService bService;

}
@Service
@Scope("prototype")
public class BService {
    @Lazy
    @Autowired
    AService aService;
}

这里 @Lazy 只要一个其实就能解决问题，也可以两个都添加。

对于含有 @Async 注解的情况，也可以通过 @Lazy 注解来解决：

@Service
public class AService {
    @Autowired
    @Lazy
    BService bService;

    @Async
    public void hello() {
        bService.hello();
    }

    public BService getbService() {
        return bService;
    }
}
@Service
public class BService {
    @Autowired
    AService aService;

    public void hello() {
        System.out.println("xxx");
    }

    public AService getaService() {
        return aService;
    }
}

如此，循环依赖可破！

总而言之一句话，@Lazy 注解是通过建立一个中间代理层，来破解循环依赖的。

2. 原理分析

接下来我们再来分析一下 @Lazy 注解处理的源码。

这块的源码分析我就不从头开始分析了，因为整个处理流程前面部分和之前文章 @Autowired 到底是怎么把变量注入进来的？所介绍的内容是一致的，不熟悉的小伙伴建议先阅读 @Autowired 到底是怎么把变量注入进来的？一文。我这里就借用该文的总结，带领小伙伴们稍微回顾一下属性注入的过程：

在创建 Bean 的时候，原始 Bean 创建出来之后，会调用 populateBean 方法进行 Bean 的属性填充。
接下来调用 postProcessAfterInstantiation 方法去判断是否需要执行后置处理器，如果不需要，就直接返回了。
调用 postProcessProperties 方法，去触发各种后置处理器的执行。

在第 3 步的方法中，调用 findAutowiringMetadata，这个方法又会进一步触发 buildAutorwiringMetadata 方法，去找到包含了 @Autowired、@Value 以及 @Inject 注解的属性或者方法，并将之封装为 InjectedElement 返回。
调用 InjectedElement#inject 方法进行属性注入。

接下来执行 resolvedCachedArgument 方法尝试从缓存中找到需要的 Bean 对象。
如果缓存中不存在，则调用 resolveFieldValue 方法去容器中找到 Bean。
最后调用 makeAccessible 和 set 方法完成属性的赋值。

在第 7 步中，调用 resolveFieldValue 方法去解析 Bean，@Lazy 注解的相关逻辑就是在这个方法中进行处理的（对应 @Autowired 到底是怎么把变量注入进来的？一文的 3.2 小节）。

resolveFieldValue 方法最终会执行到 resolveDependency 方法：

@Nullable
public Object resolveDependency(DependencyDescriptor descriptor, @Nullable String requestingBeanName,
		@Nullable Set<string> autowiredBeanNames, @Nullable TypeConverter typeConverter) throws BeansException {
	descriptor.initParameterNameDiscovery(getParameterNameDiscoverer());
	if (Optional.class == descriptor.getDependencyType()) {
		return createOptionalDependency(descriptor, requestingBeanName);
	}
	else if (ObjectFactory.class == descriptor.getDependencyType() ||
			ObjectProvider.class == descriptor.getDependencyType()) {
		return new DependencyObjectProvider(descriptor, requestingBeanName);
	}
	else if (javaxInjectProviderClass == descriptor.getDependencyType()) {
		return new Jsr330Factory().createDependencyProvider(descriptor, requestingBeanName);
	}
	else {
		Object result = getAutowireCandidateResolver().getLazyResolutionProxyIfNecessary(
				descriptor, requestingBeanName);
		if (result == null) {
			result = doResolveDependency(descriptor, requestingBeanName, autowiredBeanNames, typeConverter);
		}
		return result;
	}
}

在这个方法中，首先会判断注入的属性类型是 Optional、ObjectFactory 还是 JSR-330 中的注解，我们这里都不是，所以走最后一个分支。

在最后一个 else 中，首先调用 getAutowireCandidateResolver().getLazyResolutionProxyIfNecessary 方法看一下是否需要延迟加载 Bean 对象，@Lazy 注解就是在这里进行处理的。如果能够延迟加载，那么该方法的返回值就不为 null，就可以直接返回了，就不需要执行 doResolveDependency 方法了。

ContextAnnotationAutowireCandidateResolver#getLazyResolutionProxyIfNecessary：

@Override
@Nullable
public Object getLazyResolutionProxyIfNecessary(DependencyDescriptor descriptor, @Nullable String beanName) {
	return (isLazy(descriptor) ? buildLazyResolutionProxy(descriptor, beanName) : null);
}

大家看一下，这个方法首先会调用 isLazy 去判断一下是否需要延迟加载，如果需要，则调用 buildLazyResolutionProxy 方法构建一个延迟加载的对象；如果不需要，则直接返回一个 null 即可。

protected boolean isLazy(DependencyDescriptor descriptor) {
	for (Annotation ann : descriptor.getAnnotations()) {
		Lazy lazy = AnnotationUtils.getAnnotation(ann, Lazy.class);
		if (lazy != null &amp;&amp; lazy.value()) {
			return true;
		}
	}
	MethodParameter methodParam = descriptor.getMethodParameter();
	if (methodParam != null) {
		Method method = methodParam.getMethod();
		if (method == null || void.class == method.getReturnType()) {
			Lazy lazy = AnnotationUtils.getAnnotation(methodParam.getAnnotatedElement(), Lazy.class);
			if (lazy != null &amp;&amp; lazy.value()) {
				return true;
			}
		}
	}
	return false;
}

这个判断方法主要是检查当前类中各种参数上是否含有 @Lazy 注解、方法、属性以及类名上是否含有 @Lazy 注解，如果有，则返回 true，否则返回 false。

再来看 buildLazyResolutionProxy 方法：

private Object buildLazyResolutionProxy(
		final DependencyDescriptor descriptor, final @Nullable String beanName, boolean classOnly) {
	BeanFactory beanFactory = getBeanFactory();
	final DefaultListableBeanFactory dlbf = (DefaultListableBeanFactory) beanFactory;
	TargetSource ts = new TargetSource() {
		@Override
		public Class<!--?--> getTargetClass() {
			return descriptor.getDependencyType();
		}
		@Override
		public boolean isStatic() {
			return false;
		}
		@Override
		public Object getTarget() {
			Set<string> autowiredBeanNames = (beanName != null ? new LinkedHashSet&lt;&gt;(1) : null);
			Object target = dlbf.doResolveDependency(descriptor, beanName, autowiredBeanNames, null);
			if (target == null) {
				Class<!--?--> type = getTargetClass();
				if (Map.class == type) {
					return Collections.emptyMap();
				}
				else if (List.class == type) {
					return Collections.emptyList();
				}
				else if (Set.class == type || Collection.class == type) {
					return Collections.emptySet();
				}
				throw new NoSuchBeanDefinitionException(descriptor.getResolvableType(),
						"Optional dependency not present for lazy injection point");
			}
			if (autowiredBeanNames != null) {
				for (String autowiredBeanName : autowiredBeanNames) {
					if (dlbf.containsBean(autowiredBeanName)) {
						dlbf.registerDependentBean(autowiredBeanName, beanName);
					}
				}
			}
			return target;
		}
		@Override
		public void releaseTarget(Object target) {
		}
	};
	ProxyFactory pf = new ProxyFactory();
	pf.setTargetSource(ts);
	Class<!--?--> dependencyType = descriptor.getDependencyType();
	if (dependencyType.isInterface()) {
		pf.addInterface(dependencyType);
	}
	ClassLoader classLoader = dlbf.getBeanClassLoader();
	return (classOnly ? pf.getProxyClass(classLoader) : pf.getProxy(classLoader));
}

这个方法就是用来生成代理的对象的，这里构建了代理对象 TargetSource，在其 getTarget 方法中，会去执行 doResolveDependency 获取到被代理的对象（doResolveDependency 的获取逻辑可以参考 @Autowired 到底是怎么把变量注入进来的？一文），而 getTarget 方法只有在需要的时候才会被调用。所以，@Lazy 注解所做的事情，就是在给 Bean 中的各个属性注入值的时候，原本需要去 Spring 容器中找注入的对象，现在不找了，先给一个代理对象顶着，需要的时候再去 Spring 容器中查找。

后续的逻辑我就不再多说了，小伙伴们参考 @Autowired 到底是怎么把变量注入进来的？一文即可。

好啦，现在小伙伴们明白了 @Lazy 注解是如何解决 Spring 循环依赖了吧～虽然解决了，但是我们在日常开发中，要是能避免循环依赖还是要去避免～ </string></string>

微信关注我们

原文链接：https://my.oschina.net/lenve/blog/10089610

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

浅析本地缓存技术-Guava Cache | 京东物流技术团队

1 引言作为java开发工作者，相信大家对于guava这个工具包都不会太陌生，而对于本地缓存技术guava cache，大家在日常的工作开发中也都有所了解，接下来本文就从各个角度入手来对于Google提供的guava cache进行解析。 2 guava cache应用场景本地缓存的数据读写都在一个进程内，相对与redis等分布式缓存，不需要网络传输的过程，访问速度很快，同时也受到JVM内存的制约，无法在数据量较多的场景下使用。基于以上特点，guava cache的主要应用场景为以下几种：对于访问速度有较大要求存储的数据不经常变化数据量不大，占用内存较小需要访问整个集合能够容忍数据不是实时的在这里guava cache被用于储存参数配置，也符合以上的应用场景条件。 3 guava cache的使用方式 guava cache位于com.google.common.cache包下，核心的类有两个，一个是CacheBuilder，是用来构建缓存的，另一个是Cache，也就是缓存容器，用来存放缓存数据的。要使用guava cache，首先要引入maven依赖： <d...

2023-07-20

842

作者：vivo 互联网服务器团队 - Wang Zhi Redis 作为互联网业务首选的远程缓存工具而被大面积使用，作为访问客户端的 Jedis 同样被大面积使用。本文主要分析 Redis3.x 版本集群模式发生主从切换场景下 Jedis 的参数设置不合理引发服务雪崩的过程。一、背景介绍 Redis作为互联网业务首选的远程缓存工具而被被大家熟知和使用，在客户端方面涌现了Jedis、Redisson、Lettuce等，而Jedis属于其中的佼佼者。目前笔者的项目采用Redis的3.x版本部署的集群模式（多节点且每个节点存在主从节点），使用Jedis作为Redis的访问客户端。日前Redis集群中的某节点因为宿主物理机故障导致发生主从切换，在主从切换过程中触发了Jedis的重试机制进而引发了服务的雪崩。本文旨在剖析Redis集群模式下节点发生主从切换进而引起服务雪崩的整个过程，希望能够帮助读者规避此类问题。二、故障现场记录消息堆积告警【MQ-消息堆积告警】告警时间：2022-11-29 23:50:21 检测规则: 消息堆积阈值:-》异常( >100000) 告警服务...

2023-07-19

315

资源下载

更多资源

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。