Java의 정적 바인딩 및 동적 바인딩에 대한 자세한 소개

Java 프로그램을 실행하려면 컴파일과 실행(해석)이라는 두 단계가 필요합니다. 동시에 Java는 객체 지향 프로그래밍 언어입니다. 하위 클래스와 상위 클래스의 메서드가 동일하고 하위 클래스가 상위 클래스의 메서드를 재정의하는 경우 프로그램이 런타임에 해당 메서드를 호출할 때 상위 클래스의 메서드를 호출해야 할까요, 아니면 하위 클래스의 재정의된 메서드를 호출해야 할까요? Java를 처음 배울 때 문제가 발생해야 합니다. 여기에서는 먼저 어떤 메서드를 호출할지 또는 변수 작업을 바인딩이라고 할지 결정합니다.

Java에는 두 가지 바인딩 방법이 있는데, 하나는 초기 바인딩이라고도 하는 정적 바인딩입니다. 다른 하나는 동적 바인딩(후기 바인딩이라고도 함)입니다.

차이 비교

1. 정적 바인딩은 컴파일 타임에 발생하고, 동적 바인딩은 런타임에 발생합니다.
2. 프라이빗 또는 정적 또는 최종 수정된 변수나 메소드를 사용하고, 정적 바인딩을 사용합니다. 가상 메서드(하위 클래스에 의해 재정의될 수 있는 메서드)는 런타임 개체를 기반으로 동적으로 바인딩됩니다.
3. 정적 바인딩은 클래스 정보를 사용하여 완료하고, 동적 바인딩은 객체 정보를 사용하여 완료해야 합니다.
4. 오버로드된 메서드는 정적 바인딩을 사용하여 완성되고, 재정의된 메서드는 동적 바인딩을 사용하여 완성됩니다.

오버로드 방식의 예시

오버로드 방식의 예시는 다음과 같습니다.

public class TestMain {
  public static void main(String[] args) {
      String str = new String();
      Caller caller = new Caller();
      caller.call(str);
  }
  static class Caller {
      public void call(Object obj) {
          System.out.println("an Object instance in Caller");
      }
      
      public void call(String str) {
          System.out.println("a String instance in in Caller");
      }
  }
}

실행 결과는

22:19 $ java TestMain
a String instance in in Caller

입니다. 위 코드에는 호출 메소드의 오버로드된 구현이 두 개 있습니다. 하나는 Object 유형의 객체를 매개변수로 받고, 다른 하나는 String 유형의 객체를 매개변수로 받습니다. str은 String 객체이며, String 유형 매개변수를 받는 모든 호출 메서드가 호출됩니다. 여기서 바인딩은 컴파일 타임의 매개변수 유형을 기반으로 하는 정적 바인딩입니다.

검증

외관만으로는 정적으로 바인딩되어 있음을 확인할 수 없습니다. javap를 사용하여 컴파일하면 됩니다.

22:19 $ javap -c TestMain
Compiled from "TestMain.java"
public class TestMain {
  public TestMain();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return
  public static void main(java.lang.String[]);
    Code:
       0: new           #2                  // class java/lang/String
       3: dup
       4: invokespecial #3                  // Method java/lang/String."<init>":()V
       7: astore_1
       8: new           #4                  // class TestMain$Caller
      11: dup
      12: invokespecial #5                  // Method TestMain$Caller."<init>":()V
      15: astore_2
      16: aload_2
      17: aload_1
      18: invokevirtual #6                  // Method TestMain$Caller.call:(Ljava/lang/String;)V
      21: return
}

18번째 줄을 봤습니다: Invokevirtual #6 // Method TestMain$Caller.call:(Ljava/lang/String;)V는 실제로 정적으로 바인딩되어 있으며 호출이 String을 수신한 것으로 확인됩니다. 호출자 메서드에 대한 매개변수인 개체입니다.

오버라이딩 메소드 예시

public class TestMain {
  public static void main(String[] args) {
      String str = new String();
      Caller caller = new SubCaller();
      caller.call(str);
  }
  
  static class Caller {
      public void call(String str) {
          System.out.println("a String instance in Caller");
      }
  }
  
  static class SubCaller extends Caller {
      @Override
      public void call(String str) {
          System.out.println("a String instance in SubCaller");
      }
  }
}

실행 결과는

22:27 $ java TestMain
a String instance in SubCaller

위 코드에서는 Caller에 call 메소드가 구현되어 있고 SubCaller가 Caller를 상속합니다. , 그리고 호출 메소드의 구현이 다시 작성되었습니다. Caller 유형의 callerSub 변수를 선언했지만 이 변수는 SubCaller 개체를 가리킵니다. 결과에 따르면 Caller의 call 메소드 대신 SubCaller의 call 메소드 구현을 호출하는 것을 알 수 있다. 이러한 결과가 나오는 이유는 동적 바인딩이 런타임에 발생하고 바인딩 프로세스 중에 호출할 호출 메서드 구현의 버전을 결정해야 하기 때문입니다.

검증

동적 바인딩은 javap를 사용하여 직접 검증할 수 없으며, 정적 바인딩을 수행하지 않는다는 것이 증명되면 동적 바인딩을 수행한다는 의미이다.

22:27 $ javap -c TestMain
Compiled from "TestMain.java"
public class TestMain {
  public TestMain();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return
  public static void main(java.lang.String[]);
    Code:
       0: new           #2                  // class java/lang/String
       3: dup
       4: invokespecial #3                  // Method java/lang/String."<init>":()V
       7: astore_1
       8: new           #4                  // class TestMain$SubCaller
      11: dup
      12: invokespecial #5                  // Method TestMain$SubCaller."<init>":()V
      15: astore_2
      16: aload_2
      17: aload_1
      18: invokevirtual #6                  // Method TestMain$Caller.call:(Ljava/lang/String;)V
      21: return
}

위와 같이 18: Invokevirtual #6 // Method TestMain$Caller.call:(Ljava/lang/String;)V 여기에서는 TestMain$SubCaller 호출 대신 TestMain$Caller.call이 있습니다. , 컴파일러는 하위 클래스 또는 상위 클래스의 구현을 호출할지 여부를 결정할 수 없기 때문에 런타임 시 동적 바인딩을 통해서만 처리할 수 있습니다.

오버로딩이 오버라이딩을 만나는 경우

다음 예는 Caller 클래스에 호출 메서드에 두 가지 오버로드가 있습니다. 더 복잡한 것은 SubCaller가 Caller를 통합하고 이 두 개를 다시 작성한다는 것입니다. 행동 양식. 사실 이 상황은 위의 두 상황이 복합된 상황이다.

다음 코드는 먼저 정적 바인딩을 수행하여 매개변수가 String 객체인 호출 메서드를 결정한 다음 런타임에 동적 바인딩을 수행하여 하위 클래스 또는 상위 클래스의 호출 구현을 실행할지 여부를 결정합니다.

public class TestMain {
  public static void main(String[] args) {
      String str = new String();
      Caller callerSub = new SubCaller();
      callerSub.call(str);
  }
  
  static class Caller {
      public void call(Object obj) {
          System.out.println("an Object instance in Caller");
      }
      
      public void call(String str) {
          System.out.println("a String instance in in Caller");
      }
  }
  
  static class SubCaller extends Caller {
      @Override
      public void call(Object obj) {
          System.out.println("an Object instance in SubCaller");
      }
      
      @Override
      public void call(String str) {
          System.out.println("a String instance in in SubCaller");
      }
  }
}

실행 결과는

22:30 $ java TestMain
a String instance in in SubCaller

검증

위에서 소개했으므로 디컴파일 결과만 여기에 올리겠습니다

22:30 $ javap -c TestMain
Compiled from "TestMain.java"
public class TestMain {
  public TestMain();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return
  public static void main(java.lang.String[]);
    Code:
       0: new           #2                  // class java/lang/String
       3: dup
       4: invokespecial #3                  // Method java/lang/String."<init>":()V
       7: astore_1
       8: new           #4                  // class TestMain$SubCaller
      11: dup
      12: invokespecial #5                  // Method TestMain$SubCaller."<init>":()V
      15: astore_2
      16: aload_2
      17: aload_1
      18: invokevirtual #6                  // Method TestMain$Caller.call:(Ljava/lang/String;)V
      21: return
}

궁금한 질문

동적 바인딩 없이는 불가능한가요?

실제로 이론적으로 특정 메소드의 바인딩은 정적 바인딩으로도 달성할 수 있습니다. 예를 들면 다음과 같습니다.

public static void main(String[] args) {
      String str = new String();
      final Caller callerSub = new SubCaller();
      callerSub.call(str);
}

예를 들어 여기서 callerSub는 subCaller의 객체를 보유하고 있으며 callerSub 변수는 final이며 호출 메서드는 이론적으로 즉시 실행됩니다. 컴파일러는 SubCaller의 호출 메서드를 알 수 있습니다. 코드를 충분히 분석하여 호출해야 합니다.

근데 왜 정적 바인딩이 없나요?
Caller가 호출 메소드를 구현하는 특정 프레임워크의 BaseCaller 클래스에서 상속되고 BaseCaller가 SuperCaller에서 상속된다고 가정합니다. 호출 메소드는 SuperCaller에서도 구현됩니다.

특정 프레임워크 1.0

static class SuperCaller {
  public void call(Object obj) {
      System.out.println("an Object instance in SuperCaller");
  }
}
  
static class BaseCaller extends SuperCaller {
  public void call(Object obj) {
      System.out.println("an Object instance in BaseCaller");
  }
}

에서 BaseCaller 및 SuperCaller를 가정하고 이를 구현하기 위해 프레임워크 1.0을 사용합니다. Caller는 BaseCaller를 상속하고 super.call 메소드를 호출합니다.

public class TestMain {
  public static void main(String[] args) {
      Object obj = new Object();
      SuperCaller callerSub = new SubCaller();
      callerSub.call(obj);
  }
  
  static class Caller extends BaseCaller{
      public void call(Object obj) {
          System.out.println("an Object instance in Caller");
          super.call(obj);
      }
      
      public void call(String str) {
          System.out.println("a String instance in in Caller");
      }
  }
  
  static class SubCaller extends Caller {
      @Override
      public void call(Object obj) {
          System.out.println("an Object instance in SubCaller");
      }
      
      @Override
      public void call(String str) {
          System.out.println("a String instance in in SubCaller");
      }
  }
}

그런 다음 정적 바인딩이 위 Caller의 super.call이 BaseCaller.call로 구현되었음을 확인할 수 있다고 가정하고 이 프레임워크 버전 1.0을 기반으로 클래스 파일을 컴파일했습니다.

그런 다음 BaseCaller가 이 프레임워크 버전 1.1에서 SuperCaller의 호출 메서드를 재정의하지 않는다고 다시 가정합니다. 그런 다음 정적으로 바인딩될 수 있는 호출 구현이 버전 1.1에서 문제를 일으킬 것이라고 가정합니다. 1.1 super. 호출은 정적 바인딩에 의해 결정되는 BaseCaller의 호출 메소드가 아닌 SuperCall의 호출 메소드를 사용하여 구현되어야 합니다.

따라서 실제로 정적으로 바인딩할 수 있는 것들도 보안성과 일관성을 고려하여 단순히 동적으로 바인딩할 뿐입니다.

최적화에 대한 영감을 얻으셨나요?

동적 바인딩은 런타임에 실행할 메서드 구현이나 변수의 버전을 결정해야 하기 때문에 정적 바인딩보다 시간이 더 많이 걸립니다.

따라서 전체 디자인에 영향을 주지 않고 private, static 또는 final을 사용하여 메서드나 변수를 수정하는 것을 고려할 수 있습니다.

Java의 정적 바인딩과 동적 바인딩에 대한 자세한 소개는 PHP 중국어 홈페이지를 참고해주세요!