This mode is identical to autowire by type. The only difference is, in this case, the autowire happens to constructor arguments rather than properties of the bean. When Spring encounters autowire with constructor mode, it will try to search and bind the bean's constructor argument with exactly one bean of the same type. Let's understand this by looking at the following example:

public class StudentService {
  public void getStudentDetail() {
    System.out.println(" This is Student details.. ");
  }
}

public class ExamService {
  private StudentService studentService;
  private String examServiceType;
  
  public ExamService(StudentService studentService, String examServiceType) {
    this.studentService=studentService;
    this.examServiceType = examServiceType;
  }
  
  public void getExamDetails() {
    if(studentService !=null) {
      //Business logic to get exam details.
      
      studentService.getStudentDetail();
    }
  }
}

In the preceding code, ExamService  depends on StudentService. ExamService has a constructor through which Spring will inject the dependency of StudentService. The previous scenario can be configured in Spring as follows:

 <!-- Example of autowire by Constructor -->
<bean id="studentService" class="com.packet.spring.autowire.di.StudentService">
 </bean>
<bean id="examService" class="com.packet.spring.autowire.di.ExamService" autowire="constructor">
     <constructor-arg value="Science Exam"/>
</bean>

When Spring scans the attribute autowire="constructor" for the bean examService, it will search and inject any bean with the same type as examService's constructor. In our case, we are using one constructor argument of the StudentService class, so Spring will inject the instance of the studentService bean, which we defined in the previous XML file.

Similar to autowire by type mode, if there is more than one bean with a matching type to the constructor argument type, Spring will throw an error. Along with autowire = constructor mode, you can still pass any additional arguments through the <constructor-arg> element shown in the previous configuration. If we hadn't used autowire here, we would have passed the studentService with the <constructor-arg> element. 

In spite of the preceding advantages, the autowire feature should be used with a little caution. Following are the points you need to take into consideration while using it:

• Autowire can't be applied to primitive types.
• In case there are multiple beans of the same type, it will cause errors while using autowire by type and constructor, though there are options to avoid this.
• Since autowiring happens silently by Spring, sometimes it's difficult to find the logical issue when there are plenty of beans defined in the Spring application context files. 
• People still prefer explicit mapping rather than autowiring, because explicit mapping is somewhat more accurate, clear, and more readable as well.