Public Class ArrayList

You might also like

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 4

public class ArrayList<E> extends AbstractList<E> implements List<E>,

RandomAccess, Cloneable, Serializable

Resizable-array implementation of the List interface. Implements all optional list


operations, and permits all elements, including null. In addition to implementing the List
interface, this class provides methods to manipulate the size of the array that is used
internally to store the list. (This class is roughly equivalent to Vector, except that it is
unsynchronized.)

The size, isEmpty, get, set, iterator, and listIterator operations run in constant
time. The add operation runs in amortized constant time, that is, adding n elements requires
O(n) time. All of the other operations run in linear time (roughly speaking). The constant
factor is low compared to that for the LinkedList implementation.

Each ArrayList instance has a capacity. The capacity is the size of the array used to store
the elements in the list. It is always at least as large as the list size. As elements are added to
an ArrayList, its capacity grows automatically. The details of the growth policy are not
specified beyond the fact that adding an element has constant amortized time cost.

An application can increase the capacity of an ArrayList instance before adding a large
number of elements using the ensureCapacity operation. This may reduce the amount of
incremental reallocation.

Note that this implementation is not synchronized. If multiple threads access an


ArrayList instance concurrently, and at least one of the threads modifies the list
structurally, it must be synchronized externally. (A structural modification is any operation
that adds or deletes one or more elements, or explicitly resizes the backing array; merely
setting the value of an element is not a structural modification.) This is typically
accomplished by synchronizing on some object that naturally encapsulates the list. If no
such object exists, the list should be "wrapped" using the
Collections.synchronizedList method. This is best done at creation time, to prevent
accidental unsynchronized access to the list:

List list = Collections.synchronizedList(new ArrayList(...));

The iterators returned by this class's iterator and listIterator methods are fail-fast: if
the list is structurally modified at any time after the iterator is created, in any way except
through the iterator's own remove or add methods, the iterator will throw a
ConcurrentModificationException. Thus, in the face of concurrent modification, the
iterator fails quickly and cleanly, rather than risking arbitrary, non-deterministic behavior at
an undetermined time in the future.

Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally
speaking, impossible to make any hard guarantees in the presence of unsynchronized
concurrent modification. Fail-fast iterators throw ConcurrentModificationException on
a best-effort basis. Therefore, it would be wrong to write a program that depended on this
exception for its correctness: the fail-fast behavior of iterators should be used only to detect
bugs.

This class is a member of the Java Collections Framework.

Vector

The Vector class implements a growable array of objects. Like an array, it contains
components that can be accessed using an integer index. However, the size of a Vector can
grow or shrink as needed to accommodate adding and removing items after the Vector has
been created.

Each vector tries to optimize storage management by maintaining a capacity and a


capacityIncrement. The capacity is always at least as large as the vector size; it is
usually larger because as components are added to the vector, the vector's storage increases
in chunks the size of capacityIncrement. An application can increase the capacity of a
vector before inserting a large number of components; this reduces the amount of
incremental reallocation.

The Iterators returned by Vector's iterator and listIterator methods are fail-fast: if the Vector
is structurally modified at any time after the Iterator is created, in any way except through
the Iterator's own remove or add methods, the Iterator will throw a
ConcurrentModificationException. Thus, in the face of concurrent modification, the Iterator
fails quickly and cleanly, rather than risking arbitrary, non-deterministic behavior at an
undetermined time in the future. The Enumerations returned by Vector's elements method
are not fail-fast.

Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally
speaking, impossible to make any hard guarantees in the presence of unsynchronized
concurrent modification. Fail-fast iterators throw ConcurrentModificationException on
a best-effort basis. Therefore, it would be wrong to write a program that depended on this
exception for its correctness: the fail-fast behavior of iterators should be used only to detect
bugs.

As of the Java 2 platform v1.2, this class was retrofitted to implement the List interface,
making it a member of the Java Collections Framework. Unlike the new collection
implementations, Vector is synchronized.

Hash table

This class implements a hashtable, which maps keys to values. Any non-null object can be
used as a key or as a value.
To successfully store and retrieve objects from a hashtable, the objects used as keys must
implement the hashCode method and the equals method.

An instance of Hashtable has two parameters that affect its performance: initial capacity
and load factor. The capacity is the number of buckets in the hash table, and the initial
capacity is simply the capacity at the time the hash table is created. Note that the hash table
is open: in the case of a "hash collision", a single bucket stores multiple entries, which must
be searched sequentially. The load factor is a measure of how full the hash table is allowed
to get before its capacity is automatically increased. The initial capacity and load factor
parameters are merely hints to the implementation. The exact details as to when and
whether the rehash method is invoked are implementation-dependent.

Generally, the default load factor (.75) offers a good tradeoff between time and space costs.
Higher values decrease the space overhead but increase the time cost to look up an entry
(which is reflected in most Hashtable operations, including get and put).

The initial capacity controls a tradeoff between wasted space and the need for rehash
operations, which are time-consuming. No rehash operations will ever occur if the initial
capacity is greater than the maximum number of entries the Hashtable will contain divided
by its load factor. However, setting the initial capacity too high can waste space.

If many entries are to be made into a Hashtable, creating it with a sufficiently large
capacity may allow the entries to be inserted more efficiently than letting it perform
automatic rehashing as needed to grow the table.

This example creates a hashtable of numbers. It uses the names of the numbers as keys:

Hashtable<String, Integer> numbers


= new Hashtable<String, Integer>();
numbers.put("one", 1);
numbers.put("two", 2);
numbers.put("three", 3);

To retrieve a number, use the following code:

Integer n = numbers.get("two");
if (n != null) {
System.out.println("two = " + n);
}

The iterators returned by the iterator method of the collections returned by all of this
class's "collection view methods" are fail-fast: if the Hashtable is structurally modified at
any time after the iterator is created, in any way except through the iterator's own remove
method, the iterator will throw a ConcurrentModificationException. Thus, in the face of
concurrent modification, the iterator fails quickly and cleanly, rather than risking arbitrary,
non-deterministic behavior at an undetermined time in the future. The Enumerations
returned by Hashtable's keys and elements methods are not fail-fast.
Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally
speaking, impossible to make any hard guarantees in the presence of unsynchronized
concurrent modification. Fail-fast iterators throw ConcurrentModificationException on
a best-effort basis. Therefore, it would be wrong to write a program that depended on this
exception for its correctness: the fail-fast behavior of iterators should be used only to detect
bugs.

As of the Java 2 platform v1.2, this class was retrofitted to implement the Map interface,
making it a member of the Java Collections Framework. Unlike the new collection
implementations, Hashtable is synchronized.

You might also like