Spring的自动注入（也称为自动装配）

自动注入（也称为自动装配）是Spring框架中的一个核心概念，它与手动装配相对立，提供了一种更简洁、更灵活的方式来管理Bean之间的依赖关系。

在Spring应用程序中，如果类A依赖于类B，通常需要在类A中定义一个类型为B的属性，并提供相应的setter方法。然而，在自动注入的上下文中，我们无需在XML配置文件中显式地描述这两个类之间的依赖关系。当Spring容器启动时，它会根据配置自动实例化bean。在实例化类A的过程中，Spring容器会检查类A的属性，并尝试自动装配这些属性。由于Spring容器能够识别类A依赖于类B（通过反射或其他机制），它会自动将合适的类B的实例注入到类A的对应属性中。这种由Spring容器自动处理依赖关系的方式称为自动注入。

而与之相对的是手动装配，即程序员在XML配置文件中显式地指定bean之间的依赖关系。在手动装配中，程序员需要明确告诉Spring容器哪些bean应该被注入到哪些属性中。

总结来说，自动注入是Spring框架提供的一种简化依赖管理的机制，它通过自动解析bean之间的依赖关系来减少手动配置的工作量。而手动装配则需要程序员在配置文件中显式地指定依赖关系，如下：

在这里插入图片描述

package com.zhaoshu.xmlioc;
import com.zhaoshu.di.A;
import com.zhaoshu.xmlioc.service.UserService;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class Test {
    @org.junit.jupiter.api.Test
    void testdi() {
        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");
        A a = (A) context.getBean("a");
        a.print();
    }
}

但是实际开发中手动装配的场景比较少(比如在缺少源码的情况下可能会使用这种手动装配情况)。

在Spring框架中，依赖注入（DI）是实现控制反转（IOC）的重要手段，它允许对象在运行时从外部源接收其依赖项，而不是通过硬编码或构造函数参数来创建它们。DI主要有两种主要的实现方式：基于构造方法的依赖注入和基于setter方法的依赖注入。然而，这两种方式并不是唯一的，它们还有各自的变体形式。

首先，基于构造方法的依赖注入是一种常见的方式，它要求将依赖项作为参数传递给被依赖对象的构造函数。这种方式确保了依赖项在对象创建时就被注入，从而确保了对象的完整性和不变性。其次，基于setter方法的依赖注入则允许在对象创建后的某个时间点注入依赖项。它通过在对象上调用setter方法来设置依赖项的值。这种方式提供了更大的灵活性，因为可以在对象的不同生命周期阶段注入不同的依赖项。

除了这两种主要方式外，Spring还支持其他变体形式的依赖注入。例如，通过在类的属性上使用@Autowired注解，Spring可以利用Java的反射机制自动注入依赖项。这种方式可以视为setter注入方式的一种变体，因为它同样是在对象创建后注入依赖项，但无需显式调用setter方法。

在Spring中，无论是手动装配还是自动装配，本质上都是基于上述主要和变体形式的依赖注入方式来实现的。手动装配通常涉及在XML配置文件中显式地指定bean之间的依赖关系，而自动装配则通过Spring的自动检测机制自动解析bean之间的依赖关系，并在需要时注入依赖项。

在Spring框架中，当我们说“基于setter的注入”时，我们通常意味着依赖是通过一个特定的setter方法来注入的，这个setter方法通常会与类的某个私有属性相对应。但是，从Spring容器的角度来看，它并不关心这个setter方法是否确实对应了一个私有属性。在Spring的setter注入中，setter方法的存在仅仅是为了给Spring容器一个“钩子”，让容器可以在创建bean的实例时通过这个方法注入依赖。
在这里插入图片描述

因此，你可以说在Spring的setter注入中，setter方法本身并不直接依赖于类的某个私有属性。setter方法只是一个接口，允许Spring容器在创建bean时注入依赖。当然，在实际应用中，你通常会在类内部使用私有属性来保存这些依赖，以便在类的其他方法中使用它们。但这不是Spring容器所关心的，它只关心setter方法的存在和签名。

可能有的读者会认为上面的xml配置文件中已经手动装配了B给A，肯定会调用setXxx方法，其实不然，即是我使用自动装配也还是会调用的。笔者改一下代码，把A的注入模型改成自动注入来看看结果：

在这里插入图片描述

把代码改成上面这样自动装配结果是一样的，A类当中的setXxx方法还是会调用，不需要提供任何属性，可能有读者会说如果使用注解呢？比如如下代码：
在这里插入图片描述

上面代码同样会注入b，但是是调用反射机制去完成注入的，不是通过setter，当然再次说明一下这是setter的一种变体；上面代码直到A完成注入B后setter方法也不会调用。

重点来了！！！笔者看过很多资料说@Autowired也算自动装配，关于这点笔者不敢苟同，在一个属性上面加@Autowired注解应该属于手动装配，我会通过大量源码和例子来证明笔者的这个理论。

@Autowired注解被理解为自动装配的原因，主要是因为其基于类型的自动装配机制。以下是关于@Autowired和自动装配的详细解释：

  1. 自动装配的定义：
  • 在Spring框架中，自动装配是指Spring容器能够自动满足bean之间的依赖关系，而无需在配置文件中显式指定。
  1. @Autowired的作用：
  • @Autowired是Spring框架提供的一个注解，用于自动装配bean。它可以标注在成员变量、构造器或setter方法上，指示Spring容器自动查找并注入依赖的bean。
  1. 基于类型的自动装配：
  • @Autowired默认采用基于类型的自动装配。当Spring容器在创建一个bean时，会检查该bean中所有被@Autowired标注的字段、构造器参数或方法参数，并在Spring容器中查找与这些字段、参数类型相匹配的bean。
  • 如果Spring容器中只有一个与所需类型匹配的bean，那么Spring会自动将其注入到相应的字段或方法中。
  • 如果有多个与所需类型匹配的bean，Spring会抛出一个异常，除非使用其他机制（如@Qualifier注解）来指定要注入的bean。
  1. 其他机制：
  • 除了基于类型的自动装配外，Spring还支持基于名称的自动装配（例如使用@Resource注解）。但@Autowired主要是基于类型的。
  • @Autowired还可以与@Qualifier注解一起使用，以指定在多个相同类型bean存在时应该注入哪个bean。
  1. 代码示例：

@Autowired 是 Spring 框架中用于自动装配（Autowiring）的一个核心注解。它允许 Spring 容器自动解析和注入依赖项，而无需使用 XML 配置文件进行显式配置。下面我将通过几个例子来展示如何使用 @Autowired。

  1. 成员变量上的 @Autowired

假设我们有两个类，一个是 UserService 类，它依赖于 UserRepository 类。

@Service
public class UserService {

    @Autowired
    private UserRepository userRepository;

    // ... 其他方法和代码 ...

    public List<User> getAllUsers() {
        return userRepository.findAll();
    }
}

@Repository
public interface UserRepository {
    List<User> findAll();
    // ... 其他方法 ...
}

// 假设有一个实现类
@Repository
public class UserRepositoryImpl implements UserRepository {
    // 实现细节...
}

在这个例子中，UserService 类中的 userRepository 成员变量被 @Autowired 注解标记，这意味着 Spring 容器在创建 UserService 的实例时会自动查找一个 UserRepository 类型的 Bean 并将其注入到 userRepository 变量中。

  1. 构造器上的 @Autowired

从 Spring 4.3 开始，推荐在构造器上使用 @Autowired 来进行依赖注入。

@Service
public class UserService {

    private final UserRepository userRepository;

    @Autowired
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    // ... 其他方法和代码 ...
}

在这个例子中，UserService 的构造器被 @Autowired 注解标记，这意味着 Spring 容器在创建 UserService 的实例时会自动调用这个构造器，并传入一个 UserRepository 类型的 Bean 作为参数。

  1. Setter 方法上的 @Autowired

虽然现在不太推荐使用 setter 方法进行自动装配（因为构造器注入提供了更好的不可变性和测试性），但下面是一个例子：

@Service
public class UserService {

    private UserRepository userRepository;

    @Autowired
    public void setUserRepository(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    // ... 其他方法和代码 ...
}

在这个例子中，setUserRepository 方法被 @Autowired 注解标记，这意味着 Spring 容器在创建 UserService 的实例后会自动调用这个方法，并传入一个 UserRepository 类型的 Bean 作为参数。

注意事项：

  • 默认情况下，@Autowired 是按类型（byType）进行注入的。如果容器中存在多个相同类型的 Bean，你需要使用 @Qualifier 注解来指定要注入的 Bean 的名称。
  • 在使用 @Autowired 时，要确保你的类在 Spring 容器中是被管理的（即它们有 @Component、@Service、@Repository 或 @Controller 等注解）。
  • 如果你的类中有多个构造函数或多个同名的 setter 方法，你需要明确指定哪个应该用于自动装配，否则可能会引发异常。

当你的类中有多个构造函数或多个同名的 setter 方法时，Spring 容器在尝试进行自动装配时可能会遇到困惑，因为它不知道应该使用哪个构造函数或 setter 方法来注入依赖。为了解决这个问题，你可以使用 @Autowired 注解明确指定要使用的构造函数或 setter 方法，或者使用 @Primary 或 @Qualifier 注解来进一步区分 Bean。

  1. 多个构造函数

如果你有两个构造函数，并且都没有被 @Autowired 明确标记，Spring 容器将不知道在创建 Bean 时应该调用哪个构造函数。在这种情况下，通常最好只提供一个默认构造函数或者标记其中一个构造函数用于自动装配。

@Service
public class UserService {

    private final UserRepository userRepository;

    // 标记这个构造函数用于自动装配
    @Autowired
    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    // 另一个构造函数，可能用于其他目的（如测试）
    public UserService(UserRepository userRepository, AnotherDependency anotherDependency) {
        // 通常，这个构造函数不会被自动装配，除非你在某个地方明确指定了它
    }

    // ... 其他方法和代码 ...
}

在这个例子中，只有第一个构造函数被 @Autowired 标记，因此 Spring 容器在创建 UserService 的实例时会调用这个构造函数。

  1. 多个同名的 setter 方法

如果你的类中有多个同名的 setter 方法（这通常不会发生，因为 setter 方法通常遵循特定的命名约定，如 setFieldName），并且你试图使用 @Autowired 进行自动装配，Spring 容器同样会不知道应该调用哪个 setter 方法。但是，这种情况在实际开发中很少见，因为 setter 方法的命名通常是根据字段名生成的。

然而，如果你确实遇到了这种情况（可能是通过继承或其他方式），你可以使用 @Autowired 明确指定要使用的 setter 方法，或者使用 @Qualifier 来区分 Bean。但是，由于 setter 方法通常不会同名，因此这个问题通常不会出现。

  1. 使用 @Primary 或 @Qualifier 解决歧义

当你有多个相同类型的 Bean 时，你可以使用 @Primary 或 @Qualifier 来解决歧义。

  • @Primary：当存在多个相同类型的 Bean 时，标记其中一个 Bean 为首选 Bean。如果自动装配时发现多个匹配项，首选的 Bean 会被选中。
  • @Qualifier：在自动装配时，你可以使用 @Qualifier 注解明确指定要注入的 Bean 的名称。
@Repository
@Primary // 标记这个 Bean 为首选 Bean
public class PrimaryUserRepository implements UserRepository {
    // ... 实现细节 ...
}

@Repository
public class SecondaryUserRepository implements UserRepository {
    // ... 实现细节 ...
}

@Service
public class UserService {

    private UserRepository userRepository;

    @Autowired
    @Qualifier("secondaryUserRepository") // 明确指定要注入的 Bean 的名称
    public void setUserRepository(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    // ... 其他方法和代码 ...
}

在这个例子中，虽然有两个 UserRepository 类型的 Bean，但 UserService 中的 setUserRepository 方法使用 @Qualifier 注解明确指定了要注入的 Bean 的名称。同时，PrimaryUserRepository 被标记为首选 Bean，如果在其他地方没有指定特定的 Bean 名称，它将会被选中。

总结：

  • @Autowired注解之所以被理解为自动装配，是因为它能够根据字段、构造器参数或方法参数的类型，在Spring容器中自动查找并注入匹配的bean，从而实现了bean之间的自动装配。这种基于类型的自动装配机制是@Autowired注解的核心功能之一。

自动装配（Autowiring）的出现确实是为了解决手动装配时配置文件过于冗余和臃肿的问题。在Spring的早期版本中，开发者通常需要在XML配置文件中显式地定义每个bean以及它们之间的依赖关系，这对于复杂的应用程序来说可能会导致配置文件变得非常庞大和难以管理。Spring的自动装配功能通过减少配置文件中需要编写的代码量，来简化bean之间的依赖管理。它允许容器自动检测并满足bean之间的依赖关系，而无需在配置文件中显式地指定这些关系。

之所以会有人把@Autowired也理解为自动装配的原因是因为bytype引起的，因为spring官网有说明自动装配有四种模型分表是no、bytype、byname、constructor；现在流行着这么一种说法：@Autowired就是通过bytype来完成注入的。如果你也认为这种说法成立，那么就是默认了@Autowired是自动装配且装配模型是bytype。笔者见过很多程序员和很多资料都支持这种说法，其实严格意义上来讲这句话大错特错，甚至有误人子弟的嫌疑。因为bytype仅仅是一种自动注入模型而已，这种模型有其固有的技术手段，而@Autowired是一个注解，这个注解会被spring的后置处理器解析，和处理bytype不是同一回事。如果需要讲清楚他们的区别和证明@Autowired不是自动装配则首先要搞明白什么自动装配。笔者接下来会花一定篇幅来解释自动装配的知识，然后回过头来讲他们的区别和证明@Autowired属性手动装配。

如果现在已经理解了手动装配也叫手动注入，也已经理解了注入方式(setter和构造方法)，那么接下来讨论自动注入或者叫自动装配；自动注入的出现是因为手动装配过于麻烦，比如某个类X当中依赖了10个其他类那么配置文件将会变的特别冗余和臃肿，spring的做法是可以为这个X类提供一种叫做自动装配的模型，无需程序员去手动配置X类的依赖关系。有读者会疑问，用注解不也是可以解决这个xml臃肿的问题？确实用注解可以解决，但是我们现在讨论的是自动装配的问题，就不能用注解；为什么不能用注解来讨论自动装配的问题呢？因为在不配置BeanFactoryPostProcessor和修改beanDefinition的情况下注解的类是不支持自动装配的（关于BeanFactoryPostProcessor和beanDefinition的知识笔者以后有时间更新）；这也是证明@Autowired默认不是自动装配的一个证据，那又如何证明注解类是默认不支持自动装配呢？下文我会解释一个注解类默认是不支持自动装配的。也就是说如果讨论自动装配最好是用xml形式来配置spring容器才会有意义；比如下面这个例子：

在这里插入图片描述

上面代码运行起来，A能注入B，但是在xml配置文件中并没有去手动维护、描述他们之间的依赖关系，而是在xml的根标签上面写了一行default-autowire=“byType”，其实关于自动注入的歧义或者被人误解的地方就是这个default-autowire="byType"引起的；那么这行代码表示什么意思呢？表示所在配置在当前xml当中的bean都以bytype这种模式自动装配模式(如果没有特殊指定，因为bean还可以单独配置装配模式的)；这需要注意笔者的措辞，笔者说的bytype这自动装配模式，是一种模式，这个不是笔者信口开河，因为在官网文档里面spring也是这么定义的。

自动注入模型和前面提到的依赖注入方式(setter和构造方法)是两回事，简而言之：依赖注入是一个过程，主要通过setter和构造方法以及一些变体的方式完成把对象依赖、填充，这个过程叫做依赖注入，不管手动装配还是自动装配都有这个过程；而自动装配模型是一种完成自动装配依赖的手段体现，每一种模型都使用了不同的技术去查找和填充bean；

从spring官网上面可以看到spring只提出了4中自动装配模型（严格意义上是三种、因为第一种是no，表示不使用自动装配、使用），这四个模型分别用一个整形来表示，存在spring的beanDefinition当中，任何一个类默认是no这个装配模型，也就是一个被注解的类默认的装配模型是no也就是手动装配；其中no用0来表示；bytype用2来表示；

如果某个类X，假设X的bean对应的beanDefinition当中的autowireMode=2则表示这个类X的自动装配模型为bytype；如果autowireMode=1则表示为byname装配模型；需要注意的是官网上面说的四种注入模型其中并没有我们熟悉的@Autowired；可能有读者会提出假设我在A类的某个属性上面加上@Autowired之后这个A类就会不会成了自动装配呢？@Autowired是不是会改变这个类A当中的autowireMode呢？我们可以写一个例子来证明一下：

在这里插入图片描述
在这里插入图片描述

接下来笔者验证一个通过注解配置的类加上@Autowried后的注入模型的值：

在这里插入图片描述

可以看到结果为0，说明这个A类不是自动装配，其实这已经能证明@Autowried不是自动装配了，但是还有更直接的证据证明他不是自动装配，就是通过spring源码当中处理@Autowried的代码可以看出，首先我们写一个bytype的例子看看spring如何处理的：

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans.xsd"
	   default-autowire="byType">
		<!--自动装配-->
		<bean id="a" class="com.luban.app.A">
		</bean>
		<bean id="b"  class="com.luban.app.B">
		</bean>
</beans>

A.java
public class A {
	B b;
	/**
	 * 如果是自动装配需要提供setter
	 * 或者提供构造方法
	 */
	public void setB(B b) {
		this.b = b;
	}
}

B.java
public class B {
}

上面代码运行起来，调试spring源码当中的org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#populateBean方法，这个方法主要就是完成属性填充的，也就是大家说的注入：
在这里插入图片描述

可以看上图929行有一个判断，判断当前类的注入模式是否bynane或者bytype如果是其中一种则会进入930行代码执行自动装配的逻辑；因为当前代码我在xml当中配置了自动注入模型为bytype所以这里一定会进入，从上图debug的结果我们可以得知确实也进入了930行，那我们再看看@Autowried到底是否是一样的呢？
在这里插入图片描述

我们使用@Autowired注解去注入一个属性的时候spring在完成属性注入的过程中和自动注入（byname、bytype）的过程不同，spring注解跳过了那个判断，因为不成立，而是用后面的代码去完成属性注入；这也是能说明@Autowired不是自动装配的证据、更是直接打脸@Autowired是先bytype的这种说法；当然除了这个证据还有更加直接的证据，先看代码：
在这里插入图片描述

其实最关键的就是这行代码

if (ctors != null || mbd.getResolvedAutowireMode() ==AUTOWIRE_CONSTRUCTOR ||
    mbd.hasConstructorArgumentValues() || !ObjectUtils.isEmpty(args)) { return autowireConstructor(beanName, mbd, ctors, args);
}

这里有个判断 首先判断 ctors != null 然后判断类的自动注入模型是不是等于AUTOWIRE_CONSTRUCTOR（3）；分两种情况来分析：

  • 第一种情况：若我们预先设定了类的自动注入模式为通过构造函数（constructor）进行，那么相关的条件判断（采用逻辑或||操作符）将会因为至少有一个条件成立而整个if语句执行。然而，在当前的上下文中，这种情况并不适用，因为作者并未明确指定类A的自动注入模式为特定值（如数字3，这通常不是标准的自动注入模式标识）。根据提供的代码片段，我们可以观察到mbd.getResolvedAutowireMode()的返回值是0，这表示自动装配模式尚未被明确设置或默认为不进行自动装配（即autowireMode=0，对应于AutowireMode.NO）。这再次印证了，在没有明确指定的情况下，注解类默认不会启用自动注入模式。
  • 第二种情况：没有指定类的自动注入模型，笔者代码例子就是这种情况，那么spring会首先推断出构造方法，笔者A里面一个带参数的构造方法，所以再进行第一个判断ctors!=
    null的时候就已经成立了，于是也会进入。
  • 结论：在一个注解类里面提供了一个构造方法之所以能达到和自动注入的效果一样并不是因为这种方式就是自动装配，而是因为spring源码当中做了判断；使这种情况下调用的代码和自动装配调用的逻辑一下。但是有的读者会说那这样也能算自动装配啊，当然如果读者一定这么认为那么也无可厚非；

@Autowried到底和bytype有什么关系呢？为什么有资料会把他们联系在一起呢？

首先bytype是一种自动注入模型，spring会根据类型去查找一个符合条件的bean，如果没找到则不注入，程序也不会报错；如果找到多个spring也不报错，但是也不完成注入，让这个属性等于null，比如你有个接口I，提供两个实现I1和I2都存在容器当中，然后在A类当中去注入I，并且指定自动注入模型为bytype那么这个时候会找到两个符合条件的bean，spring就迷茫了，注入哪个呢？spring哪个都不注入直接让这个属性为null而且也不出异常；但是如果找到了一个那么注入的时候会调用setter，如果没有提供setter就不会。
在这里插入图片描述

spring会首先根据属性的类型去容器中找，如果没有找到在根据属性的名字找，找到了则注入，没有找到则异常，下图结果就是容器当中没有一个符合的类型和名字都不符合的则异常；
在这里插入图片描述
如果先根据类型找到了一个，那么直接注入，下图就是只有一个符合要求的类型能够完美注入；

在这里插入图片描述
如果先根据类型找到了多个，那么spring不会立马异常，而是根据名字再找去找，如果根据名字找到一个合理的则注入这个合理的，下图就是I1和I2都符合，但是spring最后却没有异常，是因为属性名字叫i1故而先类型在名字找到了合理的；

以后如果再听到@Autowried是bytype请你纠正他，bytype是一种自动注入模型；@Autowried是一个注解，两个人没有关系，一点关系都没有；@Autowried讲道理算是手动装配；那么一个注解的类到底能不能开启自动装配呢？答案是可以的，但是需要你对spring比较精通，以后笔者再更新；

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：/a/733158.html

如若内容造成侵权/违法违规/事实不符，请联系我们进行投诉反馈qq邮箱809451989@qq.com，一经查实，立即删除！

相关文章

[Redis]缓存常见问题解决(缓存穿透、击穿、雪崩一文解决!通俗易懂、代码实战!手把手教你解决缓存问题三兄弟!)

[Redis]缓存常见问题解决(缓存穿透、击穿、雪崩一文解决!通俗易懂、代码实战!手把手教你解决缓存问题三兄弟!)

Redis常见问题解决 要求 只用一种缓存技术&#xff0c;从实验点中挑一些试验进行试验原理。 1.缓存原理 目标&#xff1a;理解缓存的基本原理和工作机制。 实验步骤&#xff1a; 阅读各缓存技术机制的文档和官方资料。实现一个简单的应用程序&#xff0c;模拟数据的读写和…
阅读更多...
ffmpeg+nginx+video实现rtsp流转hls流，web页面播放

ffmpeg+nginx+video实现rtsp流转hls流，web页面播放

项目场景&#xff1a; 最近调试海康摄像头需要将rtsp流在html页面播放,因为不想去折腾推拉流&#xff0c;所以我选择ffmpeg转hls流&#xff0c;nginx转发&#xff0c;html直接访问就好了 1.首先要下载nginx和ffmpeg 附上下载地址&#xff1a; nginx nginx news ffmpeg htt…
阅读更多...
Java开发-面试题-0006-DELETE、VACUUM和TRUNCATE的区别

Java开发-面试题-0006-DELETE、VACUUM和TRUNCATE的区别

Java开发-面试题-0006-DELETE、VACUUM和TRUNCATE的区别 更多内容欢迎关注我&#xff08;持续更新中&#xff0c;欢迎Star✨&#xff09; Github&#xff1a;CodeZeng1998/Java-Developer-Work-Note 技术公众号&#xff1a;CodeZeng1998&#xff08;纯纯技术文&#xff09; …
阅读更多...
TF-IDF、BM25传统算法总结

TF-IDF、BM25传统算法总结

1. TF-IDF算法 F-IDF&#xff08;词频-逆文档频率&#xff09;是一种用于衡量文本中词语重要性的方法&#xff0c;特别适用于信息检索和文本挖掘任务。下面会拆分为两部分深入讲解TF-IDF的计算过程&#xff0c;以便更好地理解。 TF-IDF的计算过程可以分为两个主要部分&#xf…
阅读更多...
Butter Knife 8

Butter Knife 8

// 部分代码省略… Override public View getView(int position, View view, ViewGroup parent) { ViewHolder holder; if (view ! null) { holder (ViewHolder) view.getTag(); } else { view inflater.inflate(R.layout.testlayout, parent, false); holder new ViewHolde…
阅读更多...
Ansible 自动化运维实践

Ansible 自动化运维实践

随着 IT 基础设施的复杂性不断增加&#xff0c;手动运维已无法满足现代企业对高效、可靠的 IT 运维需求。Ansible 作为一款开源的自动化运维工具&#xff0c;通过简洁易用的 YAML 语法和无代理&#xff08;agentless&#xff09;架构&#xff0c;极大简化了系统配置管理、应用部…
阅读更多...
物理层（二）

物理层（二）

2.2 传输介质 2.2.1 双绞线、同轴电缆、光纤和无线传输介质 传输介质也称传输媒体&#xff0c;是数据传输系统中发送器和接收器之间的物理通路。传输介质可分为:①导向传输介质&#xff0c;指铜线或光纤等&#xff0c;电磁波被导向为沿着固体介质传播:②)非导向传输介质&…
阅读更多...
6月27日云技术研讨会 | 中央集中架构新车型功能和网络测试解决方案

6月27日云技术研讨会 | 中央集中架构新车型功能和网络测试解决方案

会议摘要 “软件定义汽车”新时代下&#xff0c;整车电气电气架构向中央-区域集中式发展已成为行业共识&#xff0c;车型架构的变革带来更复杂的整车功能定义、更多的新技术的应用&#xff08;如SOA服务化、TSN等&#xff09;和更短的车型研发周期&#xff0c;对整车和新产品研…
阅读更多...
【yolov8语义分割】跑通：下载yolov8+预测图片+预测视频

【yolov8语义分割】跑通：下载yolov8+预测图片+预测视频

1、下载yolov8到autodl上 git clone https://github.com/ultralytics/ultralytics 下载到Yolov8文件夹下面 另外&#xff1a;现在yolov8支持像包一样导入&#xff0c;pip install就可以 2、yolov8 语义分割文档 看官方文档&#xff1a;主页 -Ultralytics YOLO 文档 还能切…
阅读更多...
GLM-4V模型学习

GLM-4V模型学习

智谱AI引领技术前沿&#xff0c;推出了新一代预训练模型GLM-4系列&#xff0c;其中的GLM-4-9B作为开源版本&#xff0c;展现了其在人工智能领域的深厚实力。在语义理解、数学运算、逻辑推理、代码编写以及广泛知识领域的数据集测评中&#xff0c;GLM-4-9B及其人类偏好对齐的版本…
阅读更多...
AI音乐模型：创新还是颠覆？

AI音乐模型：创新还是颠覆？

文章目录 AI音乐大模型的崛起音乐创作门槛的降低与兴奋AI音乐作品的版权归属问题创意产业在AI阴影下的生长结语 &#x1f389;欢迎来到AIGC人工智能专栏~探索Java中的静态变量与实例变量 ☆* o(≧▽≦)o *☆嗨~我是IT陈寒&#x1f379;✨博客主页&#xff1a;IT陈寒的博客&…
阅读更多...
Apple - Text System Storage Layer Overview

Apple - Text System Storage Layer Overview

本文翻译整理自&#xff1a;Text System Storage Layer Overview&#xff08;更新日期&#xff1a;2012-09-19 https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/TextStorageLayer/TextStorageLayer.html#//apple_ref/doc/uid/10000087i 文章目录 …
阅读更多...
java：JWT的简单例子

java：JWT的简单例子

【pom.xml】 <dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId><version>2.3.12.RELEASE</version> </dependency> <dependency><groupId>org.springf…
阅读更多...
程序猿成长之路之数据挖掘篇——决策树分类算法(1)——信息熵和信息增益

程序猿成长之路之数据挖掘篇——决策树分类算法(1)——信息熵和信息增益

决策树不仅在人工智能领域发挥着他的作用&#xff0c;而且在数据挖掘中也在分类领域中独占鳌头。了解决策树的思想是学习数据挖掘中的分类算法的关键&#xff0c;也是学习分类算法的基础。 什么是决策树 用术语来说&#xff0c;决策树&#xff08;Decision Tree&#xff09;是…
阅读更多...
STM32驱动-ads1112

STM32驱动-ads1112

汇总一系列AD/DA的驱动程序 ads1112.c #include "ads1112.h" #include "common.h"void AD5726_Init(void) {GPIO_InitTypeDef GPIO_InitStructure;RCC_APB2PeriphClockCmd( RCC_APB2Periph_GPIOA | RCC_APB2Periph_GPIOC, ENABLE );//PORTA、D时钟使能 G…
阅读更多...
SQLite数据库（数据库和链表双向转换）

SQLite数据库（数据库和链表双向转换）

文章目录 SQLite数据库一、SQLite简介1、SQLite和MySQL2、基于嵌入式的数据库 二、SQLite数据库安装三、SQLite的常用命令四、SQLite的编程操作1、SQLite数据库相关API&#xff08;1&#xff09;头文件&#xff08;2&#xff09;sqlite3_open()&#xff08;3&#xff09;sqlite…
阅读更多...
Springboot拓展之整合邮件 JavaMail的使用与实操

Springboot拓展之整合邮件 JavaMail的使用与实操

邮件 电子邮件仍然是我们企业间交往的一种非常常见的方式 发送简单邮件 第一步首先导入坐标 <dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-mail</artifactId><version>2.6.13</version&…
阅读更多...
架构师指南：现代 Datalake 参考架构

架构师指南：现代 Datalake 参考架构

这篇文章的缩写版本于 2024 年 3 月 26 日出现在 The New Stack 上。 旨在最大化其数据资产的企业正在采用可扩展、灵活和统一的数据存储和分析方法。这一趋势是由企业架构师推动的&#xff0c;他们的任务是制定符合不断变化的业务需求的基础设施。现代数据湖体系结构通过将数…
阅读更多...
设计模式——设计模式原则

设计模式——设计模式原则

设计模式 设计模式原则 单一职责原则&#xff08;SPS&#xff09;&#xff1a; 又称单一功能原则&#xff0c;面向对象五个基本原则&#xff08;SOLID&#xff09;之一 原则定义&#xff1a;一个类应该只有一个发生变化的原因 使用if else进行判断实现不好维护 模式场景&a…
阅读更多...
ruoyi添加自己的菜单

ruoyi添加自己的菜单

先把自己自定义的view填写好 在菜单管理模块 因为我已经新增过&#xff0c;所以就看看我填的啥就行了 我发现一个问题&#xff0c;路由地址可以填index2或者scooldemo/index2都可以&#xff08;这个包含了文件夹路径&#xff09;&#xff0c;反正组件路径一定要填对就可以了。 …
阅读更多...
最新文章

Copyright @ 2022~2023