You should really watch "A jit does that" video by cliff click, which is just excellent, but the brief answer is this:

Java has global knowledge of all loaded classes which implement an interface. So the easy answer is, for a given call site, only one class implements a given interface. Wonderful, devirtualize it (direct calls, inline if the methods are small.) As compared to c++, you skip the vtable memory load and the jump.

They're also smart enough that, even if multiple classes implement an interface, they count who gets called at a call site and speculatively devirtualize (ie devirtualize or inline with a guard check). This is a big piece of why they're so much faster than c++.

Imagine this situation: I have an interface for probability distributions, and that interface is implemented by eg gaussian, exponential, weibull, etc. At run time, I draw a million times from one of them, then I pick another by asking the user, draw a million times, etc. So there's a tight loop that bangs on that interface over and over. In c++, you cannot devirtualize that; each call to random->getRand() involves a vtable lookup and a jump. Java will notice that, eg, you picked gaussian so the call site will be devirtualized, skipping the vtable lookup and possibly the jump. Then, later, when the user says draw a million times from poisson, it will re-virtualize it, notice it's monomorphic with a different implementation, and revirtualize it. Inlining code based on usage, and being able to change that inlining at runtime is often a very effective performance improvement technique.

Now the ugly bit, and why the jvm is one hell of a piece of engineering, is you can load classes at any time during the life of a java program, so even if at start there is only one known class implementing a given interface that can change. Therefore, you have to be able to go to already generated code and revirtualize/deoptimize it. But this magic all just works.