@Autowired 和 @Resource的区别只知道注入方式不同?那可不行,其性能上也有差距!

这篇具有很好参考价值的文章主要介绍了@Autowired 和 @Resource的区别只知道注入方式不同?那可不行,其性能上也有差距!。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录

Autowire vs Resource 性能比较

先上结论:

@Resource查找Bean的时间复杂度为O(1):

@Autowired查找Bean的时间复杂度为O(n):

不能将所有的@Resource无脑替换成@Autowired

结合源码分析Autowire vs Resource 性能比较

@Autowire注解的处理地方:

org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.AutowiredMethodElement#inject

org.springframework.beans.factory.support.DefaultListableBeanFactory#doGetBeanNamesForType:

org.springframework.beans.factory.support.AbstractBeanFactory#isFactoryBean(java.lang.String)

@Resource注解的处理地方:

org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.ResourceElement#getResourceToInject:

org.springframework.context.annotation.CommonAnnotationBeanPostProcessor#autowireResource:

@Autowired和@Resource之间的区别?表格对比版


Autowire vs Resource 性能比较

先上结论:

@Resource性能比@Autowire好很多,尤其是在bean个数较多的场景下。简单的说,@Resource相当于O(1),@Autowire相当于O(n)

@Resource查找Bean的时间复杂度为O(1):

  • @Resource注解是按照name属性进行查找的,如果没有指定name属性,那么默认是按照字段名进行查找。在Spring的DefaultListableBeanFactory类中,有一个beanDefinitionMap成员变量,这是一个HashMap,用于存储所有的Bean定义信息。当使用@Resource注解进行依赖注入时,Spring会直接根据Bean的名称在beanDefinitionMap中进行查找。由于HashMap的查找时间复杂度是O(1),所以@Resource查找Bean的时间复杂度也是O(1)。
  • 例如,如果我们有一个名为"myService"的Bean,那么我们可以使用@Resource(name = "myService")进行注入,Spring会直接在beanDefinitionMap中查找"myService",这个操作的时间复杂度是O(1)。

@Autowired查找Bean的时间复杂度为O(n):

  • @Autowired注解是按照类型进行查找的,如果有多个同类型的Bean,那么还需要配合@Qualifier注解来指定Bean的名称。当使用@Autowired注解进行依赖注入时,Spring需要遍历beanDefinitionMap中的所有Bean,找出所有类型匹配的Bean,然后再根据@Qualifier指定的名称进行筛选。由于需要遍历所有的Bean,所以@Autowired查找Bean的时间复杂度是O(n)。
  • 例如,如果我们有多个类型为MyService的Bean,那么我们可以使用@Autowired和@Qualifier("myService")进行注入,Spring会遍历所有的Bean,找出类型为MyService的Bean,然后再从中筛选出名为"myService"的Bean,这个操作的时间复杂度是O(n)。

不能将所有的@Resource无脑替换成@Autowired

@Resource注解的工作方式是首先按名称进行装配,如果没有找到对应的bean,那么再按类型进行装配。默认情况下,它在字段或者方法上,取字段名或者getter方法的属性名作为bean的名称。这种方式在大多数情况下都能正常工作,但在某些特殊情况下可能会导致查找失败。

以下是一些可能导致@Resource查找失败的情况:

  • Bean的名称与字段名不匹配:
    • 如果你的Spring配置中的bean名称与@Resource注解的字段名不匹配,那么@Resource将无法找到正确的bean。例如,如果你的bean名称是“myService”,但你的字段名是“service”,那么@Resource将无法找到正确的bean。
  • 存在多个类型相同的bean:
    • 如果你的Spring容器中存在多个类型相同的bean,那么@Resource将无法确定应该装配哪一个bean。例如,如果你有两个类型都是UserService的bean,那么@Resource将无法确定应该装配哪一个。
  • 使用了自定义的Bean名称生成策略:
    • 如果你在Spring配置中使用了自定义的Bean名称生成策略,那么@Resource可能无法找到正确的bean。因为@Resource默认是按照字段名作为bean名称进行查找的,如果你的自定义策略生成的bean名称与字段名不匹配,那么@Resource将无法找到正确的bean。

因此,虽然@Resource在大多数情况下都能正常工作,但在某些特殊情况下可能会导致查找失败。在使用@Resource时,需要注意这些潜在的问题,并根据具体的情况进行适当的处理。

结合源码分析Autowire vs Resource 性能比较

@Autowire注解的处理地方:

org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.AutowiredMethodElement#inject

  • 代码的逻辑:
    • 这段代码是Spring框架中处理@Autowired注解的关键部分,它位于AutowiredAnnotationBeanPostProcessor.AutowiredMethodElement类的inject方法中。这个方法的主要作用是将Spring容器中的bean注入到被@Autowired注解的方法的参数中。
    • 工作原理:
      • 检查是否跳过属性注入:
        • checkPropertySkipping(pvs)方法用于检查是否需要跳过当前属性的注入。如果返回true,则直接返回,不进行后续的注入操作。
      • 获取注入方法和参数:
        • 获取被@Autowired注解的方法和该方法的参数类型。
      • 解析注入参数:
        • 如果已经缓存了需要注入的参数(this.cached为true),则直接从缓存中获取参数。否则,需要解析方法的每一个参数,对于每一个参数,都会创建一个DependencyDescriptor对象,然后调用beanFactory.resolveDependency方法来解析参数对应的bean。
      • 处理解析结果:
        • 如果解析出的bean为null且该参数不是必需的(this.required为false),则将arguments设为null并跳出循环。否则,将解析出的bean添加到arguments数组中。
      • 缓存解析结果:
        • 如果arguments不为null,则将解析出的DependencyDescriptor对象和对应的bean缓存起来,以便下次直接使用。
      • 调用方法:
        • 如果arguments不为null,则使用反射调用被@Autowired注解的方法,将解析出的bean作为参数传入。
  • 代码:
    		@Override
    		protected void inject(Object bean, @Nullable String beanName, @Nullable PropertyValues pvs) throws Throwable {
    			if (checkPropertySkipping(pvs)) {
    				return;
    			}
    			Method method = (Method) this.member;
    			Object[] arguments;
    			if (this.cached) {
    				// Shortcut for avoiding synchronization...
    				arguments = resolveCachedArguments(beanName);
    			}
    			else {
    				Class<?>[] paramTypes = method.getParameterTypes();
    				arguments = new Object[paramTypes.length];
    				DependencyDescriptor[] descriptors = new DependencyDescriptor[paramTypes.length];
    				Set<String> autowiredBeans = new LinkedHashSet<>(paramTypes.length);
    				Assert.state(beanFactory != null, "No BeanFactory available");
    				TypeConverter typeConverter = beanFactory.getTypeConverter();
    				for (int i = 0; i < arguments.length; i++) {
    					MethodParameter methodParam = new MethodParameter(method, i);
    					DependencyDescriptor currDesc = new DependencyDescriptor(methodParam, this.required);
    					currDesc.setContainingClass(bean.getClass());
    					descriptors[i] = currDesc;
    					try {
    						Object arg = beanFactory.resolveDependency(currDesc, beanName, autowiredBeans, typeConverter);
    						if (arg == null && !this.required) {
    							arguments = null;
    							break;
    						}
    						arguments[i] = arg;
    					}
    					catch (BeansException ex) {
    						throw new UnsatisfiedDependencyException(null, beanName, new InjectionPoint(methodParam), ex);
    					}
    				}
    				synchronized (this) {
    					if (!this.cached) {
    						if (arguments != null) {
    							Object[] cachedMethodArguments = new Object[paramTypes.length];
    							System.arraycopy(descriptors, 0, cachedMethodArguments, 0, arguments.length);
    							registerDependentBeans(beanName, autowiredBeans);
    							if (autowiredBeans.size() == paramTypes.length) {
    								Iterator<String> it = autowiredBeans.iterator();
    								for (int i = 0; i < paramTypes.length; i++) {
    									String autowiredBeanName = it.next();
    									if (beanFactory.containsBean(autowiredBeanName) &&
    											beanFactory.isTypeMatch(autowiredBeanName, paramTypes[i])) {
    										cachedMethodArguments[i] = new ShortcutDependencyDescriptor(
    												descriptors[i], autowiredBeanName, paramTypes[i]);
    									}
    								}
    							}
    							this.cachedMethodArguments = cachedMethodArguments;
    						}
    						else {
    							this.cachedMethodArguments = null;
    						}
    						this.cached = true;
    					}
    				}
    			}
    			if (arguments != null) {
    				try {
    					ReflectionUtils.makeAccessible(method);
    					method.invoke(bean, arguments);
    				}
    				catch (InvocationTargetException ex) {
    					throw ex.getTargetException();
    				}
    			}
    		}

org.springframework.beans.factory.support.DefaultListableBeanFactory#doGetBeanNamesForType:

  • 代码的逻辑:
    • 这段代码来自Spring框架的DefaultListableBeanFactory类中的doGetBeanNamesForType方法。这个方法的主要作用是获取Spring容器中所有指定类型的bean的名称。
    • 工作原理:
      • 创建结果列表:
        • 创建一个空的列表result,用于存储找到的bean的名称。
      • 检查所有bean定义:
        • 遍历所有的bean定义(this.beanDefinitionNames),对于每一个bean定义,首先检查它是否是别名(isAlias(beanName)),如果是,则跳过。然后获取bean的合并定义(getMergedLocalBeanDefinition(beanName)),并检查这个定义是否是完整的(不是抽象的,且允许提前初始化或者已经有bean类或者不是延迟初始化或者允许提前加载类)。如果满足条件,那么就检查这个bean是否是FactoryBean,如果是,那么就尝试匹配FactoryBean创建的对象。如果匹配成功,那么就将bean的名称添加到结果列表中。
      • 处理异常:
        • 在检查bean定义的过程中,可能会抛出CannotLoadBeanClassException或BeanDefinitionStoreException异常。如果允许提前初始化(allowEagerInit为true),那么就直接抛出这些异常。否则,就忽略这些异常,并记录一条跟踪日志。
      • 检查手动注册的单例:
        • 遍历所有手动注册的单例(this.manualSingletonNames),对于每一个单例,首先检查它是否是FactoryBean,如果是,那么就尝试匹配FactoryBean创建的对象。如果匹配成功,那么就将bean的名称添加到结果列表中。然后尝试匹配FactoryBean本身。如果匹配成功,那么也将bean的名称添加到结果列表中。
      • 返回结果:
        • 将结果列表转换为字符串数组,并返回。
    • 这段代码的主要作用就是获取Spring容器中所有指定类型的bean的名称。这是Spring实现依赖注入的关键部分。
  • 代码:
    	private String[] doGetBeanNamesForType(ResolvableType type, boolean includeNonSingletons, boolean allowEagerInit) {
    		List<String> result = new ArrayList<>();
    
    		// Check all bean definitions.
    		for (String beanName : this.beanDefinitionNames) {
    			// Only consider bean as eligible if the bean name
    			// is not defined as alias for some other bean.
    			if (!isAlias(beanName)) {
    				try {
    					RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
    					// Only check bean definition if it is complete.
    					if (!mbd.isAbstract() && (allowEagerInit ||
    							(mbd.hasBeanClass() || !mbd.isLazyInit() || isAllowEagerClassLoading()) &&
    									!requiresEagerInitForType(mbd.getFactoryBeanName()))) {
    						// In case of FactoryBean, match object created by FactoryBean.
    						boolean isFactoryBean = isFactoryBean(beanName, mbd);
    						BeanDefinitionHolder dbd = mbd.getDecoratedDefinition();
    						boolean matchFound =
    								(allowEagerInit || !isFactoryBean ||
    										(dbd != null && !mbd.isLazyInit()) || containsSingleton(beanName)) &&
    								(includeNonSingletons ||
    										(dbd != null ? mbd.isSingleton() : isSingleton(beanName))) &&
    								isTypeMatch(beanName, type);
    						if (!matchFound && isFactoryBean) {
    							// In case of FactoryBean, try to match FactoryBean instance itself next.
    							beanName = FACTORY_BEAN_PREFIX + beanName;
    							matchFound = (includeNonSingletons || mbd.isSingleton()) && isTypeMatch(beanName, type);
    						}
    						if (matchFound) {
    							result.add(beanName);
    						}
    					}
    				}
    				catch (CannotLoadBeanClassException ex) {
    					if (allowEagerInit) {
    						throw ex;
    					}
    					// Probably a class name with a placeholder: let's ignore it for type matching purposes.
    					if (logger.isTraceEnabled()) {
    						logger.trace("Ignoring bean class loading failure for bean '" + beanName + "'", ex);
    					}
    					onSuppressedException(ex);
    				}
    				catch (BeanDefinitionStoreException ex) {
    					if (allowEagerInit) {
    						throw ex;
    					}
    					// Probably some metadata with a placeholder: let's ignore it for type matching purposes.
    					if (logger.isTraceEnabled()) {
    						logger.trace("Ignoring unresolvable metadata in bean definition '" + beanName + "'", ex);
    					}
    					onSuppressedException(ex);
    				}
    			}
    		}
    
    		// Check manually registered singletons too.
    		for (String beanName : this.manualSingletonNames) {
    			try {
    				// In case of FactoryBean, match object created by FactoryBean.
    				if (isFactoryBean(beanName)) {
    					if ((includeNonSingletons || isSingleton(beanName)) && isTypeMatch(beanName, type)) {
    						result.add(beanName);
    						// Match found for this bean: do not match FactoryBean itself anymore.
    						continue;
    					}
    					// In case of FactoryBean, try to match FactoryBean itself next.
    					beanName = FACTORY_BEAN_PREFIX + beanName;
    				}
    				// Match raw bean instance (might be raw FactoryBean).
    				if (isTypeMatch(beanName, type)) {
    					result.add(beanName);
    				}
    			}
    			catch (NoSuchBeanDefinitionException ex) {
    				// Shouldn't happen - probably a result of circular reference resolution...
    				if (logger.isTraceEnabled()) {
    					logger.trace("Failed to check manually registered singleton with name '" + beanName + "'", ex);
    				}
    			}
    		}
    
    		return StringUtils.toStringArray(result);
    	}

org.springframework.beans.factory.support.AbstractBeanFactory#isFactoryBean(java.lang.String)

  • 代码的逻辑:
    • 这段代码来自Spring框架的AbstractBeanFactory类中的isFactoryBean方法。这个方法的主要作用是判断指定名称的bean是否是一个FactoryBean。
    • 工作原理:
      • 获取bean名称:
        • 首先,通过transformedBeanName(name)方法获取真正的bean名称。这个方法会去掉名称前面的&字符(如果有的话),因为在Spring中,&字符表示获取FactoryBean本身,而不是FactoryBean创建的对象。
      • 检查单例实例:
        • 然后,通过getSingleton(beanName, false)方法获取单例实例。如果找到了单例实例,那么就检查这个实例是否是一个FactoryBean(beanInstance instanceof FactoryBean)。如果是,那么就返回true。
      • 检查bean定义:
        • 如果没有找到单例实例,那么就检查bean定义。如果在当前的BeanFactory中没有找到bean定义,并且父BeanFactory是一个ConfigurableBeanFactory,那么就委托给父BeanFactory来判断是否是FactoryBean(((ConfigurableBeanFactory) getParentBeanFactory()).isFactoryBean(name))。
      • 检查合并的bean定义:
        • 如果在当前的BeanFactory中找到了bean定义,那么就通过getMergedLocalBeanDefinition(beanName)方法获取合并的bean定义,然后调用isFactoryBean(beanName, mbd)方法来判断是否是FactoryBean。
    • 这段代码的主要作用就是判断指定名称的bean是否是一个FactoryBean。这是Spring处理FactoryBean的关键部分。
  • 代码:
    	@Override
    	public boolean isFactoryBean(String name) throws NoSuchBeanDefinitionException {
    		String beanName = transformedBeanName(name);
    		Object beanInstance = getSingleton(beanName, false);
    		if (beanInstance != null) {
    			return (beanInstance instanceof FactoryBean);
    		}
    		// No singleton instance found -> check bean definition.
    		if (!containsBeanDefinition(beanName) && getParentBeanFactory() instanceof ConfigurableBeanFactory) {
    			// No bean definition found in this factory -> delegate to parent.
    			return ((ConfigurableBeanFactory) getParentBeanFactory()).isFactoryBean(name);
    		}
    		return isFactoryBean(beanName, getMergedLocalBeanDefinition(beanName));
    	}

@Resource注解的处理地方:

org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.ResourceElement#getResourceToInject:

  • 代码的逻辑:
    • 这段代码来自Spring框架的CommonAnnotationBeanPostProcessor.ResourceElement类中的getResourceToInject方法。这个方法的主要作用是获取需要注入的资源。
    • 工作原理:
      • 检查是否延迟查找:
        • 首先,检查this.lazyLookup是否为true。this.lazyLookup是一个布尔值,表示是否需要延迟查找资源。如果为true,那么就需要延迟查找资源。
      • 延迟查找资源:
        • 如果需要延迟查找资源,那么就调用buildLazyResourceProxy(this, requestingBeanName)方法来构建一个延迟资源代理。这个代理会在真正需要资源时才去查找资源,这样可以提高应用程序的启动性能。
      • 立即查找资源:
        • 如果不需要延迟查找资源,那么就调用getResource(this, requestingBeanName)方法来立即查找资源。这个方法会立即查找资源,并返回查找到的资源。
    • 这段代码的主要作用就是获取需要注入的资源。这是Spring处理@Resource注解的关键部分。
  • 代码:
		@Override
		protected Object getResourceToInject(Object target, @Nullable String requestingBeanName) {
			return (this.lazyLookup ? buildLazyResourceProxy(this, requestingBeanName) :
					getResource(this, requestingBeanName));
		}

org.springframework.context.annotation.CommonAnnotationBeanPostProcessor#autowireResource:

  • 代码的逻辑:
    • 这段代码来自Spring框架的CommonAnnotationBeanPostProcessor类中的autowireResource方法。这个方法的主要作用是自动装配资源,也就是找到需要注入的资源,并返回。
    • 工作原理:
      • 检查BeanFactory类型:
        • 首先,检查传入的BeanFactory是否是AutowireCapableBeanFactory的实例。AutowireCapableBeanFactory是一个特殊的BeanFactory,它支持自动装配和其他高级特性。
      • 处理AutowireCapableBeanFactory:
        • 如果BeanFactory是AutowireCapableBeanFactory的实例,那么就获取LookupElement的依赖描述符(DependencyDescriptor),并根据依赖描述符和bean的名称来解析需要注入的资源。如果fallbackToDefaultTypeMatch为true,element.isDefaultName为true,并且BeanFactory中不包含指定名称的bean,那么就通过resolveDependency方法来解析依赖。否则,就通过resolveBeanByName方法来解析依赖。
      • 处理其他BeanFactory:
        • 如果BeanFactory不是AutowireCapableBeanFactory的实例,那么就直接通过getBean方法来获取需要注入的资源。
      • 注册依赖关系:
        • 如果BeanFactory是ConfigurableBeanFactory的实例,那么就遍历所有解析出的bean的名称,对于每一个名称,如果BeanFactory中包含这个名称的bean,那么就通过registerDependentBean方法来注册依赖关系。这样,当一个bean被销毁时,所有依赖它的bean也会被销毁。
      • 返回资源:
        • 最后,返回解析出的资源。
    • 这段代码的主要作用就是自动装配资源,也就是找到需要注入的资源,并返回。这是Spring处理@Resource注解的关键部分。
  • 代码:
	protected Object autowireResource(BeanFactory factory, LookupElement element, @Nullable String requestingBeanName)
			throws NoSuchBeanDefinitionException {

		Object resource;
		Set<String> autowiredBeanNames;
		String name = element.name;

		if (factory instanceof AutowireCapableBeanFactory) {
			AutowireCapableBeanFactory beanFactory = (AutowireCapableBeanFactory) factory;
			DependencyDescriptor descriptor = element.getDependencyDescriptor();
			if (this.fallbackToDefaultTypeMatch && element.isDefaultName && !factory.containsBean(name)) {
				autowiredBeanNames = new LinkedHashSet<>();
				resource = beanFactory.resolveDependency(descriptor, requestingBeanName, autowiredBeanNames, null);
				if (resource == null) {
					throw new NoSuchBeanDefinitionException(element.getLookupType(), "No resolvable resource object");
				}
			}
			else {
				resource = beanFactory.resolveBeanByName(name, descriptor);
				autowiredBeanNames = Collections.singleton(name);
			}
		}
		else {
			resource = factory.getBean(name, element.lookupType);
			autowiredBeanNames = Collections.singleton(name);
		}

		if (factory instanceof ConfigurableBeanFactory) {
			ConfigurableBeanFactory beanFactory = (ConfigurableBeanFactory) factory;
			for (String autowiredBeanName : autowiredBeanNames) {
				if (requestingBeanName != null && beanFactory.containsBean(autowiredBeanName)) {
					beanFactory.registerDependentBean(autowiredBeanName, requestingBeanName);
				}
			}
		}

		return resource;
	}

@Autowired和@Resource之间的区别?表格对比版

@Autowired可用于:构造函数、成员变量、Setter方法

 同

两者都可以写在字段和setter方法上;两者如果都写在字段上,那么就不需要再写setter方法;

 同

@Resource和@Autowired都是做bean的注入时使用;

@Autowired

@Resource

注入方式

@Autowired默认是按照类型 (byType) 装配注入的,默认情况下它要求依赖对象必须存在 (可以设置它required属性为false);

这会有什么问题呢? 当一个接口存在多个实现类的话,byType这种方式就无法正确注入对象了,因为这个时候 Spring 会同时找到多个满足条件的选择,默认情况下它自己不知道选择哪一个

想使用按照名称 (byName) 来装配,可以结合@Qualifier注解一起使用;

@Resource默认是按照名称 (byName) 来装配注入的,只有当找不到与名称匹配的bean才会按照类型来装配注入;

@Resource装配顺序:

  • ①如果同时指定了name和type,则从Spring上下文中找到唯一匹配的bean进行装配,找不到则抛出异常;
  • ②如果指定了name,则从上下文中查找名称(id)匹配的bean进行装配,找不到则抛出异常;
  • ③如果指定了type,则从上下文中找到类似匹配的唯一bean进行装配,找不到或是找到多个,都会抛出异常;
  • ④如果既没有指定name,又没有指定type,则自动按照byName方式进行装配;如果没有匹配,则回退为一个原始类型进行匹配,如果匹配则自动装配;

@Resource的作用相当于@Autowired,只不过@Autowired按照byType自动注入;

来源

@Autowired为Spring提供的注解,需要导入包org.springframework.beans.factory.annotation.Autowired;

@Resource并不是Spring的注解,它的包是javax.annotation.Resource,需要导入,但是Spring支持该注解的注入;

作用域

字段或属性的方法上;

字段或属性的方法上;

性能

@Autowired查找Bean的时间复杂度为O(n):

  • @Autowired注解是按照类型进行查找的,如果有多个同类型的Bean,那么还需要配合@Qualifier注解来指定Bean的名称。当使用@Autowired注解进行依赖注入时,Spring需要遍历beanDefinitionMap中的所有Bean,找出所有类型匹配的Bean,然后再根据@Qualifier指定的名称进行筛选。由于需要遍历所有的Bean,所以@Autowired查找Bean的时间复杂度是O(n)。

@Resource查找Bean的时间复杂度为O(1):

  • @Resource注解是按照name属性进行查找的,如果没有指定name属性,那么默认是按照字段名进行查找。在Spring的DefaultListableBeanFactory类中,有一个beanDefinitionMap成员变量,这是一个HashMap,用于存储所有的Bean定义信息。当使用@Resource注解进行依赖注入时,Spring会直接根据Bean的名称在beanDefinitionMap中进行查找。由于HashMap的查找时间复杂度是O(1),所以@Resource查找Bean的时间复杂度也是O(1)。

@Resource有两个重要的属性:name和 type,而Spring将@Resource注解的name属性解析为bean的名字,而type属性则解析为bean的类型;

  • 如果同时指定了name和type,则从Spring上下文中找到唯一匹配的bean进行装配,找不到则抛出异常;
  • 如果指定了name,则从上下文中查找名称(id)匹配的bean进行装配,找不到则抛出异常;
  • 如果指定了type,则从上下文中找到类似匹配的唯一bean进行装配,找不到或是找到多个,都会抛出异常;
  • 如果既没有指定name,又没有指定type,则自动按照byName方式进行装配;如果没有匹配,则回退为一个原始类型进行匹配,如果匹配则自动装配;@Resource的作用相当于@Autowired,只不过@Autowired按照byType自动注入;

当我们在使用@Autowired注解的时候,默认required=true,表示注入的时候bean必须存在,否则注入失败;

@Autowired(required=false)

不支持可选依赖文章来源地址https://www.toymoban.com/news/detail-463112.html

到了这里,关于@Autowired 和 @Resource的区别只知道注入方式不同?那可不行,其性能上也有差距!的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • @Autowired 和 @Resource 的区别是什么?

    Java面试题目录 @Autowired 和 @Resource 的区别是什么? @Autowired 是 Spring 提供的注解。默认的注入方式为byType(根据类型进行匹配)。 @Resource 是 JDK 提供的注解。默认注入方式为 byName(根据名称进行匹配)。 当一个接口存在多个实现类的情况下,@Autowired 和@Resource都需要通过名称

    2024年01月19日
    浏览(48)
  • 简述@Autowired和@Resource的区别(通俗易懂)

    前言:在日常的开发项目当中,这两个注解是经常会用到的,但是在实际使用当中好像使用起来并没有多大区别,这里我就对这两个注解进行一个详细的区别总结,通过一个完整的典型例子进行论证,思路清晰明了。 目录 一、结论 二、典型案例 2.1、准备代码 2.2、使用@A

    2024年02月03日
    浏览(50)
  • 每日一面系列-spring中@Autowired 和 @Resource 区别?

    @Autowired注解是由Spring提供的 ,它可以用来对构造方法、成员变量及方法参数进行标注,它能够根据对象类型完成自动注入,代码如下。 再来看@Resource注解,代码如下。 public class Service { @Resource(name = \\\"service1\\\") private Service service1; @Resource(name = \\\"service2\\\") private Service service2; @Reo

    2024年02月12日
    浏览(46)
  • 五个维度,解析 Spring 中 @Autowired 和 @Resource 的区别

    @Autowired注解是由Spring提供的,它可以用来对构造方法、成员变量及方法参数进行标注,它能够根据对象类型完成自动注入,代码如下: 再来看@Resource注解,代码如下: 它是由JDK提供的,遵循JSR-250规范,是JDK 1.6及以上加入的新特性。作为Java的标准,它的作用和@Autowired无区别

    2024年02月12日
    浏览(40)
  • 【Spring实战】28 @Autowired 和 @Resource注解的区别与使用

    Spring 框架是一个强大的 Java 企业应用开发框架, 提供了多种依赖注入的方式 。其中, @Autowired 和 @Resource 是两个常用的注解,用于实现依赖注入。本文将介绍这两个注解的区别以及在实际应用中如何进行选择。 1)匹配方式 @Autowired 是由 Spring 框架提供的注解,用于实现自动

    2024年01月21日
    浏览(55)
  • @Autowired和@Resource注解之间的关系区别,Bean的作用域和生命周期,Spring的执行流程

    目录 一. @Autowired 和 @Resource 注解 二. Bean的作用域  1. singleton(单例模式) 2. prototype(原型模式)(多例模式) 3. 请求作用域:request 4. 会话作用域:session 三. Spring 的执行流程 四. Bean 的生命周期   1. 实例化  2. 设置属性  3. Bean 初始化      3.1 执行各种各种 Aware 通知;     

    2024年02月04日
    浏览(64)
  • @Autowired 注入为null 的原因与解决方式

    我们经常会通过@Autowired注解将某个类注到另一个类中,但是会发现注不进去,报NULL。 可能的原因有一下几种: (1)该类没有托管给spring 管理 一般在类的上面添加@Component 就可以了 (2)你的这个类有被new出来的实例的,new 过的对象不会交给Spring容器管理 所以里面的 ser

    2024年02月11日
    浏览(34)
  • 开发经验分享之:import引入包和@Autowired注入类有什么区别

    大家好,我是三叔,很高兴这期又和大家见面了,一个奋斗在互联网的打工人。 import 和 @Autowired 想必大家在 Java 开发中使用频率最多的之一了把,这篇博客将解释这两个概念的区别和作用,帮助你更好地理解它们在Java开发中的应用。 import引入包 在 Java 中,import 关键

    2024年02月14日
    浏览(42)
  • Spring高手之路-@Autowired和@Resource注解异同点

    目录 概述 相同点 1.都可以实现依赖注入 2.都可以用于注入任意类型的Bean 3.都支持通过名称、类型匹配进行注入 不同点 1.来源不同。 2.包含的属性不同 3.匹配方式(装配顺序)不同。 4.支持的注入对象类型不同 5.应用地方不同 @Autowired 和 @Resource 是在 Java 开发中用于实现依赖

    2024年02月03日
    浏览(47)
  • WPF Prism MVVM技巧【用注入方式在不同项目中访问主窗体(MainWindow)】

    提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档 目的是想在Prism MVVM中通过注入的方式来全局访问主窗体(MainWindow)。 创建一个Prism Full App(WPF)项目,在Services项目文件夹中创建一个Public_Global项目并创建一个Global.cs类用来注入。 Dongming_BigTest.App.xmal.c

    2024年02月05日
    浏览(41)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包