As far as keeping track of your explosions, a large array is probably great for prototyping something small, but as you're discovering, it doesn't scale well and passing it around can get ugly. Here are a couple of solutions:

1. Implement an ExplosionManager. Pros: No need to pass around a reference to your explosions array. Easy to group updates of elements it's responsible for. Cons: High coupling between it and the sections of codes that utilize it. Still a rather specific reference to a game element (which brings me to suggestion two...)
2. Implement a proper scene graph. This is most definitely a larger undertaking than option one. In the case of an explosion, when something in the game creates one, the explosion is parented to it in the graph, automatically allowing it to be rendered. Pros: Explosions (and all other game elements) can be treated generically (think GameObject from Unity). Lower coupling than option one. Cons: Significant amount of work. Sometimes not efficient to scatter updates of like-objects.

As far as creating chain reactions, you could have an explosion query objects in the game environment which are a certain distance away, and communicate to them that there is an explosion happening nearby. The objects react accordingly.

MarkR already provided a good answer for your issues with modifying a list while operating on it. My only suggestion on top of this is to copy the list before operating on it and operate on the copy. It can be a little less confusing than working with 'new' and 'dead' object arrays.

As far as keeping track of your explosions, a large array is probably great for prototyping something small, but as you're discovering, it doesn't scale well and passing it around can get ugly. Here are a couple of solutions:

1. Implement an ExplosionManager. Pros: No need to pass around a reference to your explosions array. Easy to group updates of elements it's responsible for. Cons: High coupling between it and the sections of codes that utilize it. Still a rather specific reference to a game element (which brings me to suggestion two...)
2. Implement a proper scene graph. This is most definitely a larger undertaking than option one. In the case of an explosion, when something in the game creates one, the explosion is parented to it in the graph, automatically allowing it to be rendered. Pros: Explosions (and all other game elements) can be treated generically (think GameObject from Unity). Lower coupling than option one. Cons: Significant amount of work. Sometimes not efficient to scatter updates of like-objects.

As far as creating chain reactions, you could have an explosion query objects in the game environment which are a certain distance away, and communicate to them that there is an explosion happening nearby. The objects react accordingly.

MarkR already provided a good answer for your issues with modifying a list while operating on it. My only suggestion on top of this is to copy the list before operating on it and operate on the copy. It can be a little less confusing than working with 'new' and 'dead' object arrays.

Update: An ExplosionManager would be implemented as a singleton with global access. My Java is rusty, but the resulting code would look something like:

ExplosionManager.addExplosion(new Explosion());

Somewhere in your game's main update loop you have:

ExplosionManager.update(deltaTime);

The class' responsibility is to oversee the existence of every explosion in your game. It holds onto them for their lifetimes, and updates them. Example code and an explanation of the singleton pattern can be found here.

As far as the scene graph is concerned, yes, it's a lot. It comes down to how much of an investment you want to make. If your game is very small and there are no plans to branch it into another project, you don't really need a scene graph. If the game is going to become large though, or you plan on making other games from the architecture of this one, then a scene graph might be a good investment. I could end up writing a lot about scene graphs, so for more information I'll refer you to the Wikipedia page.