basically avoiding synch is a bad idea for the reason that you'll always face this problem if you have more than one leading thread, which is the often case with games. But another one would let off synch to perform the tests while it will start to synchronize its code at a later time.
With Swing applications like a Text Editor or a simple FTP manager, rendering is handled by the AWT EventQueue. That is you call repaint() which will notify the queue of AWT. Then AWT sends an update() callback to the components within the default timer-rate (usually unknown).
For "Active Rendering", I've just been working on it with a simple Pong-like game where the programmer choose the moment the render will occur, that is AWT is not involved. Say you want a 60Hz refresh rate, so your timer will tick at 60Hz and your program will render the scene at 60Hz. This way brings the best results, but need quite a thought before to begin coding. Yes, you define a refresh-rate, but rendering can take more time to complete and will probably go over the next timer-tick. No synch is needed for a simple game like Pong, nor the simpliest Space Invaders. But if you want to full up the scene with some of your best Sprites, you may use synchronization. That is one of the main topic for Active Rendering.
Synching two Threads is not so easy but no post will replace a simple book about this topic. Plus, active Rendering is commonly meant to use Pipelines, e.g. the Direct3D pipeline or OpenGL pipeline. You might be facing the usual hard- and soft-rendering which are quite similar.
Let's say if I had to write a book about Java AWT I'd include this well undiscovered topic!