详细分析Java类调用Service接口失效的注意事项（附Demo）

前言

试错了一小时，发现接口返回null！！
最后梳理其知识点并总结其原理

1. 问题所示

接口类如下：

public interface IInfoService extends BaseService<Info> {

错误方式一：（此处infoservice返回null值）

错误方式二：（不使用注解，通过new实例化 也返回null值）

2. 原理分析

在Spring MVC中，@Autowired和@Resource等注解通常用于在Controller中注入Service，这是因为在Spring MVC中，Controller属于Spring容器的一部分，因此可以自动注入其他由Spring管理的Bean，如Service

然而，在一般的类中，如果想要使用Service，直接使用new关键字实例化一个Service对象是不可取的


这是因为通过new实例化的对象是脱离了Spring容器的管理的，因此无法获取到Spring容器中的注解属性值，这样可能会导致注入的Service为null。
即使该类被标记为@Component并且被Spring管理，直接通过new实例化Service的方式也无法注入依赖，因为这个实例不受Spring容器的管控。

为了解决这个问题，应该让这个一般类也成为Spring容器的一个Bean，方法是使用@Component或者相关的注解，如@Service、@Repository等。然后，在需要使用Service的地方，通过注入的方式将Service注入到这个一般类中，而不是通过new关键字实例化。这样就能保证依赖注入成功，避免出现null的情况。

在实践中，确保了类成为了Spring容器的一个Bean，并使用了适当的注解来进行依赖注入，可以有效避免由于依赖注入失败而导致的空指针异常等问题

springboot不支持注入静态属性，使用`@Autowired等注解注入会失败

3. 解决方法

使用如下方式：

@Component
public class CommonUtil {

	@Autowired
	private IInfoService infoService;

	public static CommonUtil commonUtil;

	@PostConstruct
	public void init() {
		commonUtil = this;
	}

最终在调用inforservice方法时，通过使用commonUtil.infoService.list

主要的步骤逻辑如下：

1. @Component注解标记了CommonUtil类，使其成为了Spring容器的一个Bean，因此Spring会对其进行管理
2. @Autowired注解标记了infoService字段，告诉Spring在初始化CommonUtil的时候，自动注入一个IInfoService类型的实例
3. @PostConstruct注解标记了init()方法，这意味着在CommonUtil实例创建完成并且所有的依赖注入完成后，Spring会调用init()方法。在init()方法中，将当前实例赋值给了静态的commonUtil对象
4. 通过将commonUtil对象设置为静态的，使得其他类可以通过CommonUtil.commonUtil来访问CommonUtil类的实例，从而间接获取到了IInfoService的实例

这种方法虽然能够解决在普通类中使用Service的问题，但要注意以下几点：

• 静态变量commonUtil可能存在线程安全问题，如果多个线程同时访问该变量，可能会出现竞态条件。
• 静态变量的使用会增加类的耦合度，降低代码的可维护性和可测试性。