代码
@Autowiredprivate JedisServer jedisServer;此时@AutoWired上面有黄色的波浪线作为正告，正告的内容是
Field injection is not recommended 大抵的意思是，不倡议以变量注入
芝士
依赖注入的形式有三种
- 变量（filed）注入
- 结构器注入
- set办法注入
各自的注入形式如下
*变量(filed)注入
@Autowiredprivate JedisServer jedisServer;*结构器注入
final UserDao userDao; @Autowired public UserServiceImpl(UserDao userDao) { this.userDao = userDao; }- set办法注入
private UserDao userDao; @Autowired public void setUserDao (UserDao userDao) { this.userDao = userDao; }三种办法比较而言
长处：变量形式注入十分简洁，没有任何多余代码，十分无效的进步了java的简洁性。即便再多几个依赖一样能解决掉这个问题。
毛病：不能无效的指明依赖。置信很多人都遇见过一个bug，依赖注入的对象为null，在启动依赖容器时遇到这个问题都是配置的依赖注入少了一个注解什么的，然而这种形式就过于依赖注入容器了，当没有启动整个依赖容器时，这个类就不能运行，在反射时无奈提供这个类须要的依赖。
在应用set形式时，这是一种抉择注入，可有可无，即便没有注入这个依赖，那么也不会影响整个类的运行。
在应用结构器形式时曾经显式注明必须强制注入。通过强制指明依赖注入来保障这个类的运行。
另一个方面：
依赖注入的核心思想之一就是被容器治理的类不应该依赖被容器治理的依赖，换成文言来说就是如果这个类应用了依赖注入的类，那么这个类解脱了这几个依赖必须也能失常运行。然而应用变量注入的形式是不能保障这点的。
既然应用了依赖注入形式，那么就表明这个类不再对这些依赖负责，这些都由容器治理，那么如何分明的晓得这个类须要哪些依赖呢？它就要应用set办法形式注入或者结构器注入。
总结下：
变量形式注入应该尽量避免，应用set形式注入或者结构器注入，这两种形式的抉择就要看这个类是强
另外将@AutoWired注解换成@Resource注解也能够将黄色正告去掉