You can navigate or access a List by using the get(index) method or an Iterator. Sometimes the get(index) method is your only option, and sometimes it's slightly faster than an Iterator. Other times, however, it can be much, much slower than an Iterator. For example, a LinkedList is a classic example. This class has a get(index) method but it is very slow. Well, it's not that bad if the list is short, or if you're looking for an item that is close to the beginning or end. But if you need to access the List frequently, you will see a big difference.
Let's take a look at the following example:
public class TestClass { public static void main(String[] args) { int len = 100000; LinkedList linkedLst = new LinkedList(); ArrayList arrayLst = new ArrayList(); for (int m =0; m!= len; m++) { int x = (int)Math.random(); linkedLst.add(x); arrayLst.add(x); } long t = System.currentTimeMillis(); for (int i = 0; i!=len; i++) { linkedLst.get(i); } t = System.currentTimeMillis() - t; System.out.println("LinkedList -- get(index) takes "+t +"(ms)"); t = System.currentTimeMillis(); for (Iterator itr = linkedLst.iterator(); itr.hasNext();) { itr.next(); } t = System.currentTimeMillis() - t; System.out.println("LinkedList -- Iterator takes "+t +"(ms)"); t = System.currentTimeMillis(); for (int i = 0; i!=len; i++) { arrayLst.get(i); } t = System.currentTimeMillis() - t; System.out.println("ArrayList -- get(index) takes "+t +"(ms)"); t = System.currentTimeMillis(); for (Iterator itr = arrayLst.iterator(); itr.hasNext();) { itr.next(); } t = System.currentTimeMillis() - t; System.out.println("ArrayList -- Iterator takes "+t +"(ms)"); } }
The output is
LinkedList -- get(index) takes 25777(ms) LinkedList -- Iterator takes 0(ms) ArrayList -- get(index) takes 10(ms) ArrayList -- Iterator takes 10(ms)
And in many cases, you don't know for sure whether you want a LinkedList or an ArrayList or some other List implementation. If you use get(index), you will get the fastest possible response from an ArrayList, but you will get a very poor response from a LinkedList. If you use an Iterator, you will get something fairly close to the fastest possible response from an ArrayList, and you will get the fastest possible response from a LinkedList, too. So in general, an Iterator is a more reliable choice. It's not always the fastest possible choice, but it's always close. And it protects you from the extremely slow behavior you would get if you mistakenly used a get(index) on a LinkedList.
Also, the enhanced for loop will automatically use a hidden Iterator any time you try to loop over any Collection (or more generally, any Iterable) in JDK 5. Using an Iterator is directly supported by the language so that it's the most convenient thing for you to do - as well as being fastest, or close to fastest.
... for (Integer i:linkedLst) { System.out.println(i); } ... for (Integer i:arrayLst) { System.out.println(i); }
If more than one thread can access a Collection (or Map or array or other group-of-things), you need to synchronize. (Or use something like java.util.concurrent.locks classes from JDK 5+). No matter what you use a get(index) or an Iterator, it is not generally permissible for one thread to modify a Collection while another thread is iterating over it. In general, the results of the iteration are undefined under these circumstances. The main difference is that:
- Some Iterator implementations (including those of all the general purpose collection implementations provided by the JRE) may choose to throw ConcurrentModificationException exception if this behavior is detected. Iterators that do this are known as fail-fast iterators, as they fail quickly and cleanly, rather that risking arbitrary, non-deterministic behavior at an undetermined time in the future.
- The get(index) method will return bad data that makes very difficult to identify the real problem.
A ConcurrentModificationException is a nice signal making us easy to find the problem and to handle the problem. This is another good reason to use an Iterator.
Note that fail-fast behavior cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast operations throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: ConcurrentModificationException should be used only to detect bugs.
Did you like this article? If yes, please share with your friends..
Comments
Post a Comment