do how you like but remember that you will have been advised ....

note that synchronising mouse input make sens because until the entity is rendered to screen change made to it wont be visible to the user so making all change just before rendering ii is just "making things" at the right time.

hmm, just curious why do you want to thread you game? is it to improve performance?

if it is for faster performance, I'd try move away from using swing first rather then multithread the app.

instanceof

"Not smooth" is usually a sign of some "bursty" behavior that stalls out your game loop by forcing an iteration to run over the allotted (or reasonable) time.  For example, if you have set you game loop up to execute one fixed game step every 20 milliseconds, for a target of 50fps, then any step that runs longer than 20 milliseconds is going to feel like a stutter.  Loading images from disk disk would do it, so would a big garbage collection pause.  Switching to a time-derived step (passing an elapsed time variable) can help with this, but can be a major overhaul if you have a lot code that assumes a fixed step, and it won't help you if your  pause is a *really* big one.

I suggest:
1) Run your code through a profiler.  The netbeans one is free.  http://profiler.netbeans.org/ 
2)  Add timing calls to your main loop to capture avg, max time elapsed per loop
3)  Reduce your target framecount.  100+ fps is great for shooters, but only gives you a budget of 10 millis per frame.  25fps is a lot more forgiving.
4)  Move any heavy lifting (image IO) to a background thread.
5)  Force a low-pause garbage collector, (such as +Xincgc)
6)  If all else fails, switch your code over to a time step / as fast as possible method.  I think the Filthy Rich Clients book had some useful code, in chapter 12 - 15, http://filthyrichclients.org/