A simple multi-threading Java game with monitor pattern -- part2

In part 1, we represent the enemy locations in a HashMap and use a threadSafe monitor to control the access.

In part 2, we will add a new thread to update the enemy tank locations. We also add a new feature to make the demo game less boring -- allowing the enemy to kill our tank.

The game will evolve, so ...

The current code version in the video suffer multithreading issue, the first shot sometimes does not display correctly. (to reproduce on my machine, close and reopen eclipse, the first shot of the first play will have this problem)

The buggy code is here:

Before the next video, please exam
* how many threads are involved?
* Identify the variables that form the GameBoard's state.
* Identify the invariants that constrain the state variables.
* Are all swing component methods invoked from the event dispatch thread? Are these methods labelled "thread safe" in the API specification?

Remember, in the absence of synchronization, the compiler, processor, and runtime can do some downright weird things to the order in which operations appear to execute. Attempts to reason about the order in which memory actions "must" happen in insufficiently synchronized multithreaded programs will almost certainly be incorrect.