@Alaa That doesn't affect Vector's thread safety. Vector is internally synchronized, so
single operations are Thread-safe. However, the issue is there are no transactional operations like I described above with removing every other element.
// in Thread A
my_vec.add(new Object());
// in Thread B
my_vec.add(new Object());
This is perfectly thread safe, even if there is no wrapping synchronized block or any other synchronization methods.
// in Thread A
// remove last element
my_vec.remove(my_vec.size() - 1);
// in Thread B
my_vec.remove(0);
This is not synchronized correctly! The problem is there are a total of 2 operations required by Thread A to be done as a single transaction.
Suppose my_vec.size() initially is 5.
Thread A calls my_vec.size(), retrieves 5.
Thread B decides it wants to remove the first element. This is done synchronously as a single step, so the actual size of my_vec is now 4.
Thread A calls my_vec.remove(4). Kaboom! You get an out of range exception because there is no 4th element. The last element is actually at index 3 now.
Fixing this code:
// in Thread A
synchronized(my_vec)
{
my_vec.remove(my_vec.size() - 1);
}
// in Thread B
synchronized(my_vec)
{
my_vec.remove(0);
}
This is perfectly fine, until you realize that Thread A had to acquire 3 locks just to remove the last element. Additionally, every other Thread must now at a minimum acquire 2 locks to do any operation. Technically if Vector internally uses synchronized(this) you could get away without the synchronized block in thread B, but as far as I can tell there's no guarantees on what type of locking Vector provides so this is a very bad thing to rely on. This is an example of too much synchronization.
@AndrewR
Luckily for you, there's not much learning involved. The two classes implement the same interfaces so you can call the same methods and expect basically the same results. Simply declare your variables as ArrayList and you're good