JMM - Java memory model

JMM
An archtecture's memory model tells programs what guarantees they can expect from the memory system, and specifies the special instructions required (called memory barriers) to get the additional memory coordination guarantees required when sharing data.

The JMM defines a partial ordering called happens-before on all actions within the program. To guarantee that the thread executing action B can see the results of action A, there must be a happens-before relationship between A and B. In the absence of a happens-before ordering between two operations, the JVM is free to reorder them as is pleases.

The rules for happen-before are:

Program order rule. Each action in a thread happens-before every action in that thread that comes later in the program order.

Monitor lock rule. An unlock on a monitor lock happens-before every subsequent lock on that same monitor lock.

Volatile variable rule. A write to a volatile field happens-before every subsequent read of that same field.

Thread start rule. A call to Thread.start on a thread happens-before every action in the started thread.

Thread termination rule. Any action in a thread happens-before any other thread detects that thread has terminated, either by successfully return from Thread.join or by Thread.isAlive returning false.

Interruption rule. A thread calling interrupt on another thread happens-before the interrupted thread detects the interrupt.

Finalizer rule. The end of a constructor for an object happens-before the start of the finalizer for that object.

Transitivity. If A happens-before B, and B happens-before C, then A happens-before C.

Failure at job interview

What to do if you got rejected after the interview or you've just failed it?

Do not despair. Do not take rejection as your tragedy. Life is not only success. Often there are failures. This is not good or bad. This is just a norm of life.

After the interview try to understand which questions you couldn't answer?

Interview is a good opportunity to check your knowledge as well as to understand what the company is all about you are going to work on?

After you could identify your gaps in knowledge you can learn and fix it. Every subsequent interview increase your chances for success.

After every interview you increase the knowledge of market needs. In the end you'll land your job.

Concurrent collections. Java 8

Concurrent collections.

What are the reasons to use new concurrent collections when we can use old plain collections using wrappers like Collections.synchronized(List/Set/Map)? The problem in this case will be that all accesses to the collection will use one lock. In its turn this will slow down performance.

We can ask what is the price in this case? For example take a look at HashTable and ConcurrentHashMap by the following link: https://www.ibm.com/developerworks/java/library/j-jtp07233/index.html.

Here are the results:
Threads    ConcurrentHashMap    Hashtable
1    1.00    1.03
2    2.59    32.40
4    5.58    78.23
8    13.21    163.48
16    27.58    341.21
32    57.27    778.41

Absolute numbers are not important but it is more valid to compare relative numbers.

What can we do about it? Maybe it will be better to write our own implementation of concurrent collection? It it possible but hard to achieve and more over there are already good implementations. Many useful concurrent collections are located at  java.util.concurrent package.

Concurrent collections make synchronized collections largely obsolete.

That way instead of HashMap one can use ConcurrentHashMap.
In case when a number of search iterations outnumbers the number of adding or removing operations one can use CopyOnWriteArrayList instead of ArrayList.

As for the Queue implementations there are a lot of implementations:

    1. LinkedBlockingQueue — an optionally bounded FIFO blocking queue backed by linked nodes. An optionally-bounded blocking queue based on linked nodes.  Linked queues typically have higher throughput than array-based queues but less predictable performance in most concurrent applications. The optional capacity bound constructor argument serves as a way to prevent excessive queue expansion. The capacity, if unspecified, is equal to Integer.MAX_VALUE. Linked nodes are dynamically created upon each insertion unless this would bring the queue above capacity.
   
    2. ArrayBlockingQueue — a bounded FIFO blocking queue backed by an array. A bounded blocking queue backed by an array.
   
    3. ConcurrentLinkedQueue - An unbounded thread-safe queue based on linked nodes. This queue orders elements FIFO (first-in-first-out). This implementation employs an efficient non-blocking algorithm based on one described in Simple, Fast, and Practical Non-Blocking and Blocking Concurrent Queue Algorithms by Maged M. Michael and Michael L. Scott.
   
    It is not obvious which implementation to use? It depends. One should choose the implementation based on tests.
   
    4. PriorityBlockingQueue — an unbounded blocking priority queue backed by a heap. An unbounded blocking queue that uses the same ordering rules as class PriorityQueue and supplies blocking retrieval operations.

    5. DelayQueue — a time-based scheduling queue backed by a heap. An unbounded blocking queue of Delayed elements, in which an element can only be taken when its delay has expired. 
   
    6. SynchronousQueue — a simple rendezvous mechanism that uses the BlockingQueue interface. Synchronous queues are similar to rendezvous channels used in CSP and Ada. They are well suited for handoff designs, in which an object running in one thread must sync up with an object running in another thread in order to hand it some information, event, or task.

 7. In JDK 7, TransferQueue is a specialized BlockingQueue in which code that adds an element to the queue has the option of waiting (blocking) for code in another thread to retrieve the element. TransferQueue has a single implementation:

    LinkedTransferQueue — an unbounded TransferQueue based on linked nodes. This implementation outperforms SynchronousQueue by factor of 3 to 14. See http://cs.oswego.edu/pipermail/concurrency-interest/2009-February/005886.html.
   
Deques and work stealing.
    Just as blocking queues lend themselves to the producer-consumer pattern, deques lend themselves to a related pattern called work stealing.

Java. How to start learning threads.

There are a lot of different ways to start learning Java threads.
Here is my approach to learn threads:

1. Read the Java language tutorials on concurrency at https://docs.oracle.com/javase/tutorial/essential/concurrency/index.html.
2. Learn basic constructs like synchronized and volatile.
3. Learn about Dinning philosophers problem.
4. Read Effective Java Programming Language guide 3rd edition section 11 Concurrency:
1. Item 78. Synchronize access to shared mutable data
2. Item 79. Avoid excessive synchronization
3. Item 80. Prefer executors, tasks and streams to threads
4. Item 81. Prefer concurrency utilities to wait and notify
5. Item 82. Document thread safety
6. Item 83. Use lazy initialization judiciously
7. Item 84. Don't depend on the thread scheduler
5. Try to read Java Concurrency in Practice.

I'm not sure I have covered everything, but it is a good ground to start with.
Regards.

Java synchronized keyword

Java multithreading has 2 key aspects - visibility and automicity.

• For synchronization in Java one can use synchronized keyword. 
• Keyword synchronized is not equivalent to atomic, but synchronization can be used to achieve atomicity. 
• When subclassing a class overridden method should also define synchronized in its signature. 
• A synchronized method can call another synchronized method on its own instance.

Java volatile keyword

According to Java Language Specification 8 section 8.3.1.4:
"As a rule, to ensure that shared variables are consistently and reliably updated, a thread should ensure that it has exclusive use of such variables by obtaining a lock that, conventionally, enforces mutual exclusion for those shared variables.

The Java programming language provides a second mechanism, volatile fields, that is more convenient than locking for some purposes. 

A field may be declared volatile, in which case the Java Memory Model ensures that all threads see a consistent value for the variable" .

Please note, that volatile doesn't imply atomic.  So that if your code is like this:
private volatile int var = 0;
var = var+1;
and you run increment in 2 threads then result won't be 2 in all situations.
In other words volatile fix visibility problems but not race conditions.

I recommend to go by following link https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.3.1.4 and take a look at example.

From Concurrent programming in Java 2nd:

• Declaring a reference field as volatile does not ensure visibility of non- volatile fields that are accessed via this reference. 
• Similarly, declaring an array field as  volatile does not ensure visibility of its elements. 
• Volatility cannot be manually propagated for arrays because array elements themselves cannot be declared as volatile. 

Declaring fields as  volatile can be useful when you do not need locking for any other reason, yet
values must be accurately accessible across multiple threads. This may occur when:

• The field need not obey any invariants with respect to others.
• Writes to the field do not depend on its current value.
• No thread ever writes an illegal value with respect to intended semantics.
• The actions of readers do not depend on values of other non-volatile fields.

Stages of the programmers interview

Here is a short list of possible stages of the interview.

Phone screening. Usually is conducted by recruiter to assure that your phone is correct and you remember what is written in your resume. :-)
Time spent: 20-30 minutes.

Tet-a-tet meeting or Skype interview. This meeting is usually a technical interview where people try to check what you know and what you don't. Resembles like an oral exam. If you prepared well then you can come through it. But sometimes you are given a task which you need to solve or design a system.
Time spent: 1-1.5 hours.

Technical test over the Internet. As a rule you are given some time for a couple of easy technical tasks or a test with answer options. Many companies have their own platforms for such tests, but as a rule no one is supporting them, but the tests are chosen from a given limited set.

But there are exceptions. Some companies use third party sites which provide tests with different type of difficulty: from the middle one to hardcore.
Time spent: 1-1.5 hours.

Testing task. Usually you are given a code for refactoring or being asked to write a simple implementation of some task like a REST controller. It is not recommended to spend more than 3-4 hours on it. The less the better. Value your time. If necessary you can add something by saying when your task will be reviewed. If you are given a real peace of code and asked to do some "production" task then it is better to deny such offer as it may turned out that a company is doing its job for free.
Time spent: 1-3 hours.

Live coding. The most stressful part. People are watching you and how you code. Imagine how your productivity goes down with this approach? Usually no difficult tasks are given, but it is easy to fail. People try to check how you think, but in my opinion this way allows only to check your stress resistance.
Time spent: 0.5-1 hour.

Meeting with manager. At this stage manager is trying to understand how adequate you are and who you are from a business point of you? Are you a team player?
Time spent: 0.5-1 hour.


Mostly this is it. Usually there are no more then 3 stages including phone interview. This process is
very time consuming for you and a company. So it is better to keep short all the stages as possible.

If we'll talk about time then if we sum up all the timings it will be between 4 hours 20 minutes and 8 hours. Usually not all stages are being conducted. For example live coding is often omitted. This timings doesn't include your questions to the company. So expect to add between 0.5 and 1 hour for your questions and company's answers.

Java 8 programming interview questions

Hi all.
I decided to share with you some stuff which could be useful for the beginners.

Every time you go to the Java interview you almost always get the familiar set of questions. Here is the list of questions that in my opinion are commonly asked at the interviews.

I won't give answers in this post for now. Feel free to explore them on your own.

• Class Object in Java. Methods equals, hashCode, toString. Default implementation.
• StringBuilder and StringBuffer. What is the difference? Compare strings by == and equals. String pool.
• Collections. Basic interfaces and collections. ArrayList and LinkedList. HashMap default implementation. Difference between HashMap and LinkedHashMap and TreeMap.
• Threads. Thread class. Interface Runnable. Monitor object. Methods wait, notify, notifyAll. Interface Executor. Synchronized keyword. Volatile keyword. Thread-safe collections. Dining philosophers.
• Difference between interface and abstract class.
• Lambda expressions. Default methods in interfaces.
• Exceptions. Checked and unchecked. Difference.
• Keyword final on class, method, instance member variable, method argument.
• Try/catch/finally. Cases when finally block will not get executed. 
• Basic principles of garbage collector.
• GoF templates. Examples. Do not mention Singleton. Visitor, Adapter, Builder, Template method, Strategy.
• Basic SOLID principles.
• What is TDD?

 One of my favorite question is the following: you've got a class which contains one synchronized and one non synchronized method. What will happen if on one instance of this class will operate two threads, one will call synchronized method the other one will call non synchronized method? Is it possible to occur at once?

Answer: One thread can call synchronized method and another one can call  non synchronized method. Synchronized keyword means that a thread needs to obtain object's monitor first. If there are no such word on a method then nothing stops the second thread to operate on an object.

Usually there are other questions about Spring, Databases, J2EE but let's leave it for now. 

That is all for now. Good luck!

Java 8. Files.lines() can cause possible resource leak.

Files.lines() method allows to receive stream of lines from file.
It seems to be very convenient apart from one thing - it can cause resource leak.
You must close this stream explicitly or use try with resource block.

It seems to be strange that terminal operations in this case doesn't close the resources underneath a stream.

Kotlin. Good point.

Hi!
Long time no see.

What I'm currently observing is the rise of Kotlin language. Kotlin is the child of JetBrains company which brought to us IntelliJ.
Why Kotlin could in the future replace Java? What are the selling points of Kotlin?
Let's try to figure this out:

1. Kotlin works on JVM.
2. Kotlin can use all the java libraries.
3. Java can call code written in Kotlin.
4. Kotlin is open source.
5. Kotlin is developed and supported by JetBrains.
6. Google officially supports Kotlin as a second development language on Android platform.
7. IntelliJ has very good support tooling for Kotlin.
8. Spring Boot supports Kotlin.
9. Spring Framework 5 supports Kotlin.
10. Kotlin can be translated to java script.

With Kotlin you can migrate the project in Java in small steps.

Is not it enough to sell Kotlin to management and start using it in production?