It's a
test harness and it's purpose is to test the locking mechanism of your Data class and that could be easily done with just 1 iteration. It's all about the update1 and delete1
thread to compete for the lock on record 1. So you certainly have to test that situation. But it even could be that the test runs to completion but still have an issue with your Data class, because the threads ran in a given order and the problem in your code only manifests itself when these threads run in some other order.
So indeed executing 100 times delete1 and update1 is pretty useless, therefor I suggested to add a random delete thread (like the update random thread), but this don't give you the guarantee that 2 threads will compete for the same record (a guarantee which you have with delete1 and update1 threads) and like I already indicated that's a situation you certainly want to test, because that's likely the cause of any issues (of threads not running to completion).
You could also re-use record numbers of deleted entries and then it makes more sense, because the create thread will create a record at position 1 (if the delete1 thread deleted this record already) or at the end of the map (otherwise), so the RNFE will not be thrown that frequently. And I don't know if my good buddy Roberto re-used record numbers of deleted entries, but he shared his test case with the community and you are free to adjust and make changes to this test to make it fit your needs. I re-used record numbers of deleted entries, so I had a whole bunch of thread pairs competing with each other to get a lock on the same record and that helped me to discover an issue in my locking mechanism. If you decided not to re-use these record numbers (it's not a must requirement) you could maybe adjust the code to have a delete and update thread which try to gain the lock of the same record, but not always record 1.
Hope it makes things a bit more clear.