The functions that ABCL uses in Threads.java are thread.interrupt and thread.isInterrupted. It overrides interrupt and isInterrupted to implement interrupt-thread - by saving away the function the target thread is to be interrupted with. Remember, interrupt-thread isn't executed by the thread to be interrupted, it's called from another thread. The receiving thread handles InterruptedException, which is only called on explicit check of interrupt state or from sleep or wait.
Separately, in Lisp.Java there's setInterrupted and handleInterrupt that don't use the java mechanism. Rather setInterrupted sets a static volatile Lisp.interrupted, handleInterrupted clears the variable and calls break. setInterrupted, as I said, is only called from interrupt-lisp. Code generation inserts checks of Lisp.interrupted and calls handleInterrupted if it is set. I have a feeling that this part was done so that frequent interrupt checks could be made without taking the performance hit of a synchronized method call. Remember this check is done inside every loop iteration. The check for Lisp.interrupted is a volatile read, which in most cases is handled in the cache. A write to the volatile invalidates the cache forcing the new value to be read from memory. So much less expensive.
It would be useful to know the history of how it came to be that there are two different interrupt mechanisms.