Java Language and Core Concepts

Collections

Understand Java Collections and Thread Safetywww.codejava.net

Not thread safe

• ArrayList

• LinkedList

• HashMap

• HashSet

• TreeMap

• TreeSet

Thread safe

Blocking synchronization

We can wrap any collection using synchronizedXXX wrapper. But it uses syncronise blocks to do it's magic. It means that other thread should wait, which comes at a performance decrease.

Another option is to use collections which are using Lock object (i.e. semaphore) (note: it can use many).

• LinkedBlockingQueue (Producer Consumer scenarios)

• ArrayBlockingQueue (Producer Consumer scenarios)

• ConcurrentHashMap

Legacy:

• Vector

• Hashtable

Non-blocking synchronization

• CAS (Compare and Swap)

  • ConcurrentLinkedQueue

  • ConcurrentSkipListMap

  • Atomic(Long, Int ...)

• CoW (Copy on Write)

  • CopyOnWriteArrayList

  • CopyOnWriteArraySet

  • copy-on-write collections have snapshot iterators which do not throw ConcurrentModificationException.

Generics

Bounded generics are using super or extends keywords. Wildcard is ?

Deep dive into Java Generics(0x01)jp-wang.github.io

Multithreading

Difference between binary semaphore and mutexStack Overflow

ThreadPools:

Concurrency

Fail-fast iterators iterating over collection in one thread and change from other thread, the first thread will though ConcurrentModificationException.

Fail Safe Iterator makes copy of the internal data structure (object array) and iterates over the copied data structure.

Java memory management

OOP

SOLID

Design patters

The .equals() Contract

Java SE defines the contract that our implementation of the equals() method must fulfill. In short, most criteria follow common sense but we can define the formal rules that the equals() method must follow. It must be:

• reflexive: an object must equal itself

• symmetric: x.equals(y) must return the same result as y.equals(x)

• transitive: if x.equals(y) and y.equals(z), then also x.equals(z)

• consistent: the value of .equals() should change only if a property that is contained in .equals() changes (no randomness allowed)

Java SE also defines a contract for the .hashCode() method. A thorough look at this contract reveals how closely related .hashCode() and .equals() are.

All three criteria in the .hashCode() contract mention the .equals() method in some way:

• internal consistency: the value of hashCode() may only change if a property that is in equals() changes

• equals consistency: objects that are equal to each other must return the same hashCode

• collisions: unequal objects may have the same hashCode