Java Specialists' Java Training Europehome of the java specialists' newsletter

Newsletters related to Concurrency

Issue Subject Date
242 Concurrency Puzzle Explained, Solved With StampedLock
Most programmers had a blind spot with the statement "arr[size++] = e;" We somehow think that size will be updated after the assignment. In this newsletter we look at this basic concurrency bug and also present a solution in the form of the Java 8 StampedLock.
241b Concurrency Puzzle Useful Hints
In the previous newsletter, we sent out a threading puzzle for you to solve. Here are some hints to help you figure out what is going on.
241 Concurrency Puzzle - System.arraycopy()
"Friends don't let friends write low level concurrency by themselves." -@karianna. Here is your chance to participate in a global code review puzzle to figure out what's going on in some synchronized code.
234 Random Code Failures - Race Conditions Between Our Code and the JVM
Most of the time our code fails because of bugs in our code. Rarely, however, bugs in the JVM ecosystem cause our systems to fail. These are insanely difficult to diagnose in production systems. In this newsletter we look at two different such race conditions between our code and the JVM.
218 Thread Confinement
One of the techniques we use to ensure that a non-threadsafe class can still be used by multiple threads is to give each thread its own instance. We call this "thread confinement". In this newsletter we look at some of the issues that can happen when this instance leaks.
214 CountingCompletionService
CompletionService queues finished tasks, making it easier to retrieve Futures in order of completion. But it lacks some basic functionality, such as a count of how many tasks have been submitted.
206 Striped Executor Service
We present a new type of ExecutorService that allows users to "stripe" their execution in such a way that all tasks belonging to one stripe are executed in-order.
202 Distributed Performance Tuning
In this newsletter, it is up to you to figure out how we improved the performance of our previous Fibonacci newsletter by 25%.
201 Fork/Join With Fibonacci and Karatsuba
The new Java 7 Fork/Join Framework allows us to define our algorithms using recursion and then to easily parallelize them. In this newsletter we describe how that works using a fast Fibonacci algorithm that uses the sum of the squares rather than brute force. We also present a faster algorithm for multiplying two large BigInteger numbers, using the Fork/Join Framework and the Karatsuba algorithm.
196 Uncaught AWT Exceptions in Java 7
Java 7 removes the Swing Event Dispatch Thread (EDT) hack that allowed us to specify an uncaught exception handler for the EDT using a system property sun.awt.exception.handler.
194 trySynchronize
Did you know that it possible to "try" to synchronize a monitor? In this newsletter we demonstrate how this can be used to avoid deadlocks and to keep the wine coming.
192b How Does "this" Escape?
A quick follow-up to the previous newsletter, to show how the ThisEscape class is compiled, causing the "this" pointer to leak.
192 Implicit Escape of "this"
We should never allow references to our objects to escape before all the final fields have been set, otherwise we can cause race conditions. In this newsletter we explore how this is possible to do.
188 Interlocker - Interleaving Threads
In this newsletter, we explore a question of how to call a method interleaved from two threads. We show the merits of lock-free busy wait, versus explicit locking. We also discuss an "unbreakable hard spin" that can cause the JVM to hang up.
184 Deadlocks through Cyclic Dependencies
A common approach to ensuring serialization consistency in thread safe classes such as Vector, Hashtable or Throwable is to include a synchronized writeObject() method. This can result in a deadlock when the object graph contain a cyclic dependency and we serialize from two threads. Whilst unlikely, it has happened in production.
160 The Law of the Uneaten Lutefisk
Imagine a very stubborn viking father insisting that his equally stubborn child eat its lutefisk before going to sleep. In real life one of the "threads" eventually will give up, but in Java, the threads become deadlocked, with neither giving an inch. In this newsletter we discover how we can sometimes escape from such deadlocked situations in Java and learn why the stop() function should never ever ever be called.
159 The Law of Sudden Riches
We all expect faster hardware to make our code execute faster and better. In this newsletter we examine why this is not always true. Sometimes the code breaks on faster servers or executes slower than on worse hardware.
156 The Law of Cretan Driving
The Law of Cretan Driving looks at what happens when we keep on breaking the rules. Eventually, we might experience a lot of pain when we migrate to a new architecture or Java Virtual Machine. Even if we decide not to obey them, we need to know what they are. In this newsletter, we point you to some essential reading for every Java Specialist.
155 The Law of the Micromanager
In good Dilbert style, we want to avoid having Pointy-Haired-Bosses (PHBs) in our code. Commonly called micromanagers, they can make a system work extremely inefficiently. My prediction is that in the next few years, as the number of cores increases per CPU, lock contention is going to be the biggest performance problem facing companies.
152 The Law of the Corrupt Politician
Corruption has a habit of creeping into system that do not have adequate controls over their threads. In this law, we look at how we can detect data races and some ideas to avoid and fix them.
151 The Law of the Leaked Memo
In this fifth law of concurrency, we look at a deadly law where a field value is written early.
150 The Law of the Blind Spot
In this fourth law of concurrency, we look at the problem with visibility of shared variable updates. Quite often, "clever" code that tries to avoid locking in order to remove contention, makes assumptions that may result in serious errors.
149 The Law of the Overstocked Haberdashery
Learn how to write correct concurrent code by understanding the Secrets of Concurrency. This is the third part of a series of laws that help explain how we should be writing concurrent code in Java. In this section, we look at why we should avoid creating unnecessary threads, even if they are not doing anything.
147 The Law of the Distracted Spearfisherman
Learn how to write correct concurrent code by understanding the Secrets of Concurrency. This is the second part of a series of laws that help explain how we should be writing concurrent code in Java. We look at how to debug a concurrent program by knowing what every thread in the system is doing.
146 The Secrets of Concurrency (Part 1)
Learn how to write correct concurrent code by understanding the Secrets of Concurrency. This is the first part of a series of laws that help explain how we should be writing concurrent code in Java.
093 Automatically Detecting Thread Deadlocks 2004-07-28

Extreme Java - Concurrency
Extreme Java - Advanced Topics
Refactoring to Java 8
Design Patterns
In-House Courses

© 2010-2017 Heinz Kabutz - All Rights Reserved Sitemap
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners. is not connected to Oracle, Inc. and is not sponsored by Oracle, Inc.