Java concurrency in practice

Brian Goetz, Tim Peierls

Mentioned 201

Provides information on building concurrent applications using Java.

More on Amazon.com

Mentioned in questions and answers.

I have thus far avoided the nightmare that is testing multi-threaded code since it just seems like too much of a minefield. I'd like to ask how people have gone about testing code that relies on threads for successful execution, or just how people have gone about testing those kinds of issues that only show up when two threads interact in a given manner?

This seems like a really key problem for programmers today, it would be useful to pool our knowledge on this one imho.

Have a book at the book Clean Code CHAPTER 13 there is a whole section devoted there to testing multithreaded code and also to concurrency in general which might help you design better multithreaded code.

For Java, check out chapter 12 of JCIP. There are some concrete examples of writing deterministic, multi-threaded unit tests to at least test the correctness and invariants of concurrent code.

"Proving" thread-safety with unit tests is much dicier. My belief is that this is better served by automated integration testing on a variety of platforms/configurations.

Have a look at my related answer at

Designing a Test class for a custom Barrier

It's biased towards Java but has a reasonable summary of the options.

In summary though (IMO) its not the use of some fancy framework that will ensure correctness but how you go about designing you multithreaded code. Splitting the concerns (concurrency and functionality) goes a huge way towards raising confidence. Growing Object Orientated Software Guided By Tests explains some options better than I can.

Static analysis and formal methods (see, Concurrency: State Models and Java Programs) is an option but I've found them to be of limited use in commercial development.

Don't forget that any load/soak style tests are rarely guaranteed to highlight problems.

Good luck!

It wasn't that long ago that I was a beginning coder, trying to find good books/tutorials on languages I wanted to learn. Even still, there are times I need to pick up a language relatively quickly for a new project I am working on. The point of this post is to document some of the best tutorials and books for these languages. I will start the list with the best I can find, but hope you guys out there can help with better suggestions/new languages. Here is what I found:

Since this is now wiki editable, I am giving control up to the community. If you have a suggestion, please put it in this section. I decided to also add a section for general be a better programmer books and online references as well. Once again, all recommendations are welcome.

General Programming

Online Tutorials
Foundations of Programming By Karl Seguin - From Codebetter, its C# based but the ideas ring true across the board, can't believe no-one's posted this yet actually.
How to Write Unmaintainable Code - An anti manual that teaches you how to write code in the most unmaintable way possible. It would be funny if a lot of these suggestions didn't ring so true.
The Programming Section of Wiki Books - suggested by Jim Robert as having a large amount of books/tutorials on multiple languages in various stages of completion
Just the Basics To get a feel for a language.

Books
Code Complete - This book goes without saying, it is truely brilliant in too many ways to mention.
The Pragmatic Programmer - The next best thing to working with a master coder, teaching you everything they know.
Mastering Regular Expressions - Regular Expressions are an essential tool in every programmer's toolbox. This book, recommended by Patrick Lozzi is a great way to learn what they are capable of.
Algorithms in C, C++, and Java - A great way to learn all the classic algorithms if you find Knuth's books a bit too in depth.

C

Online Tutorials
This tutorial seems to pretty consise and thourough, looked over the material and seems to be pretty good. Not sure how friendly it would be to new programmers though.
Books
K&R C - a classic for sure. It might be argued that all programmers should read it.
C Primer Plus - Suggested by Imran as being the ultimate C book for beginning programmers.
C: A Reference Manual - A great reference recommended by Patrick Lozzi.

C++

Online Tutorials
The tutorial on cplusplus.com seems to be the most complete. I found another tutorial here but it doesn't include topics like polymorphism, which I believe is essential. If you are coming from C, this tutorial might be the best for you.

Another useful tutorial, C++ Annotation. In Ubuntu family you can get the ebook on multiple format(pdf, txt, Postscript, and LaTex) by installing c++-annotation package from Synaptic(installed package can be found in /usr/share/doc/c++-annotation/.

Books
The C++ Programming Language - crucial for any C++ programmer.
C++ Primer Plus - Orginally added as a typo, but the amazon reviews are so good, I am going to keep it here until someone says it is a dud.
Effective C++ - Ways to improve your C++ programs.
More Effective C++ - Continuation of Effective C++.
Effective STL - Ways to improve your use of the STL.
Thinking in C++ - Great book, both volumes. Written by Bruce Eckel and Chuck Ellison.
Programming: Principles and Practice Using C++ - Stroustrup's introduction to C++.
Accelerated C++ - Andy Koenig and Barbara Moo - An excellent introduction to C++ that doesn't treat C++ as "C with extra bits bolted on", in fact you dive straight in and start using STL early on.

Forth

Books
FORTH, a text and reference. Mahlon G. Kelly and Nicholas Spies. ISBN 0-13-326349-5 / ISBN 0-13-326331-2. 1986 Prentice-Hall. Leo Brodie's books are good but this book is even better. For instance it covers defining words and the interpreter in depth.

Java

Online Tutorials
Sun's Java Tutorials - An official tutorial that seems thourough, but I am not a java expert. You guys know of any better ones?
Books
Head First Java - Recommended as a great introductory text by Patrick Lozzi.
Effective Java - Recommended by pek as a great intermediate text.
Core Java Volume 1 and Core Java Volume 2 - Suggested by FreeMemory as some of the best java references available.
Java Concurrency in Practice - Recommended by MDC as great resource for concurrent programming in Java.

The Java Programing Language

Python

Online Tutorials
Python.org - The online documentation for this language is pretty good. If you know of any better let me know.
Dive Into Python - Suggested by Nickola. Seems to be a python book online.

Perl

Online Tutorials
perldoc perl - This is how I personally got started with the language, and I don't think you will be able to beat it.
Books
Learning Perl - a great way to introduce yourself to the language.
Programming Perl - greatly referred to as the Perl Bible. Essential reference for any serious perl programmer.
Perl Cookbook - A great book that has solutions to many common problems.
Modern Perl Programming - newly released, contains the latest wisdom on modern techniques and tools, including Moose and DBIx::Class.

Ruby

Online Tutorials
Adam Mika suggested Why's (Poignant) Guide to Ruby but after taking a look at it, I don't know if it is for everyone. Found this site which seems to offer several tutorials for Ruby on Rails.
Books
Programming Ruby - suggested as a great reference for all things ruby.

Visual Basic

Online Tutorials
Found this site which seems to devote itself to visual basic tutorials. Not sure how good they are though.

PHP

Online Tutorials
The main PHP site - A simple tutorial that allows user comments for each page, which I really like. PHPFreaks Tutorials - Various tutorials of different difficulty lengths.
Quakenet/PHP tutorials - PHP tutorial that will guide you from ground up.

JavaScript

Online Tutorials
Found a decent tutorial here geared toward non-programmers. Found another more advanced one here. Nickolay suggested A reintroduction to javascript as a good read here.

Books
Head first JavaScript
JavaScript: The Good Parts (with a Google Tech Talk video by the author)

C#

Online Tutorials
C# Station Tutorial - Seems to be a decent tutorial that I dug up, but I am not a C# guy.
C# Language Specification - Suggested by tamberg. Not really a tutorial, but a great reference on all the elements of C#
Books
C# to the point - suggested by tamberg as a short text that explains the language in amazing depth

ocaml

Books
nlucaroni suggested the following:
OCaml for Scientists Introduction to ocaml
Using Understand and unraveling ocaml: practice to theory and vice versa
Developing Applications using Ocaml - O'Reilly
The Objective Caml System - Official Manua

Haskell

Online Tutorials
nlucaroni suggested the following:
Explore functional programming with Haskell
Books
Real World Haskell
Total Functional Programming

LISP/Scheme

Books
wfarr suggested the following:
The Little Schemer - Introduction to Scheme and functional programming in general
The Seasoned Schemer - Followup to Little Schemer.
Structure and Interpretation of Computer Programs - The definitive book on Lisp (also available online).
Practical Common Lisp - A good introduction to Lisp with several examples of practical use.
On Lisp - Advanced Topics in Lisp
How to Design Programs - An Introduction to Computing and Programming
Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp - an approach to high quality Lisp programming

What about you guys? Am I totally off on some of there? Did I leave out your favorite language? I will take the best comments and modify the question with the suggestions.

Java: SCJP for Java 6. I still use it as a reference.

Haskell:

O'Reilly Book:

  1. Real World Haskell, a great tutorial-oriented book on Haskell, available online and in print.

My favorite general, less academic online tutorials:

  1. The Haskell wikibook which contains all of the excellent Yet Another Haskell Tutorial. (This tutorial helps with specifics of setting up a Haskell distro and running example programs, for example.)
  2. Learn you a Haskell for Great Good, in the spirit of Why's Poignant Guide to Ruby but more to the point.
  3. Write yourself a Scheme in 48 hours. Get your hands dirty learning Haskell with a real project.

Books on Functional Programming with Haskell:

  1. Lambda calculus, combinators, more theoretical, but in a very down to earth manner: Davie's Introduction to Functional Programming Systems Using Haskell
  2. Laziness and program correctness, thinking functionally: Bird's Introduction to Functional Programming Using Haskell

Some books on Java I'd recommend:

For Beginners: Head First Java is an excellent introduction to the language. And I must also mention Head First Design Patterns which is a great resource for learners to grasp what can be quite challenging concepts. The easy-going fun style of these books are ideal for ppl new to programming.

A really thorough, comprehensive book on Java SE is Bruce Eckel's Thinking In Java v4. (At just under 1500 pages it's good for weight-training as well!) For those of us not on fat bank-bonuses there are older versions available for free download.

Of course, as many ppl have already mentioned, Josh Bloch's Effective Java v2 is an essential part of any Java developer's library.

Let's not forget Head First Java, which could be considered the essential first step in this language or maybe the step after the online tutorials by Sun. It's great for the purpose of grasping the language concisely, while adding a bit of fun, serving as a stepping stone for the more in-depth books already mentioned.

Sedgewick offers great series on Algorithms which are a must-have if you find Knuth's books to be too in-depth. Knuth aside, Sedgewick brings a solid approach to the field and he offers his books in C, C++ and Java. The C++ books could be used backwardly on C since he doesn't make a very large distinction between the two languages in his presentation.

Whenever I'm working on C, C:A Reference Manual, by Harbison and Steele, goes with me everywhere. It's concise and efficient while being extremely thorough making it priceless(to me anyways).

Languages aside, and if this thread is to become a go-to for references in which I think it's heading that way due to the number of solid contributions, please include Mastering Regular Expressions, for reasons I think most of us are aware of... some would also say that regex can be considered a language in its own right. Further, its usefulness in a wide array of languages makes it invaluable.

C: “Programming in C”, Stephen G. Kochan, Developer's Library.

Organized, clear, elaborate, beautiful.

C++

The first one is good for beginners and the second one requires more advanced level in C++.

I know this is a cross post from here... but, I think one of the best Java books is Java Concurrency in Practice by Brian Goetz. A rather advanced book - but, it will wear well on your concurrent code and Java development in general.

C#

C# to the Point by Hanspeter Mössenböck. On a mere 200 pages he explains C# in astonishing depth, focusing on underlying concepts and concise examples rather than hand waving and Visual Studio screenshots.

For additional information on specific language features, check the C# language specification ECMA-334.

Framework Design Guidelines, a book by Krzysztof Cwalina and Brad Abrams from Microsoft, provides further insight into the main design decisions behind the .NET library.

For Lisp and Scheme (hell, functional programming in general), there are few things that provide a more solid foundation than The Little Schemer and The Seasoned Schemer. Both provide a very simple and intuitive introduction to both Scheme and functional programming that proves far simpler for new students or hobbyists than any of the typical volumes that rub off like a nonfiction rendition of War & Peace.

Once they've moved beyond the Schemer series, SICP and On Lisp are both fantastic choices.

For C++ I am a big fan of C++ Common Knowledge: Essential Intermediate Programming, I like that it is organized into small sections (usually less than 5 pages per topic) So it is easy for me to grab it and read up on concepts that I need to review.

It is a must read for me the night before and on the plane to a job interview.

C Primer Plus, 5th Edition - The C book to get if you're learning C without any prior programming experience. It's a personal favorite of mine as I learned to program from this book. It has all the qualities a beginner friendly book should have:

  • Doesn't assume any prior exposure to programming
  • Enjoyable to read (without becoming annoying like For Dummies /
  • Doesn't oversimplify

For Javascript:

For PHP:

For OO design & programming, patterns:

For Refactoring:

For SQL/MySQL:

  • C - The C Programming Language - Obviously I had to reference K&R, one of the best programming books out there full stop.
  • C++ - Accelerated C++ - This clear, well written introduction to C++ goes straight to using the STL and gives nice, clear, practical examples. Lives up to its name.
  • C# - Pro C# 2008 and the .NET 3.5 Platform - Bit of a mouthful but wonderfully written and huge depth.
  • F# - Expert F# - Designed to take experienced programmers from zero to expert in F#. Very well written, one of the author's invented F# so you can't go far wrong!
  • Scheme - The Little Schemer - Really unique approach to teaching a programming language done really well.
  • Ruby - Programming Ruby - Affectionately known as the 'pick axe' book, this is THE defacto introduction to Ruby. Very well written, clear and detailed.

I want to run a thread for some fixed amount of time. If it is not completed within that time, I want to either kill it, throw some exception, or handle it in some way. How can it be done?

One way of doing it as I figured out from this thread is to use a TimerTask inside the run() method of the Thread.

Are there any better solutions for this?

 
EDIT: Adding a bounty as I needed a clearer answer. The ExecutorService code given below does not address my problem. Why should I sleep() after executing (some code - I have no handle over this piece of code)? If the code is completed and the sleep() is interrupted, how can that be a timeOut?

The task that needs to be executed is not in my control. It can be any piece of code. The problem is this piece of code might run into an infinite loop. I don't want that to happen. So, I just want to run that task in a separate thread. The parent thread has to wait till that thread finishes and needs to know the status of the task (i.e whether it timed out or some exception occured or if its a success). If the task goes into an infinite loop, my parent thread keeps on waiting indefinitely, which is not an ideal situation.

I think you should take a look at proper concurrency handling mechanisms (threads running into infinite loops doesn't sound good per se, btw). Make sure you read a little about the "killing" or "stopping" Threads topic.

What you are describing,sound very much like a "rendezvous", so you may want to take a look at the CyclicBarrier.

There may be other constructs (like using CountDownLatch for example) that can resolve your problem (one thread waiting with a timeout for the latch, the other should count down the latch if it has done it's work, which would release your first thread either after a timeout or when the latch countdown is invoked).

I usually recommend two books in this area: Concurrent Programming in Java and Java Concurrency in Practice.

I sort of understand that AtomicInteger and other Atomic variables allow concurrent accesses. In what cases is this class typically used though?

There are two main uses of AtomicInteger:

  • As an atomic counter (incrementAndGet(), etc) that can be used by many threads concurrently

  • As a primitive that supports compare-and-swap instruction (compareAndSet()) to implement non-blocking algorithms.

    Here is an example of non-blocking random number generator from Brian Göetz's Java Concurrency In Practice:

    public class AtomicPseudoRandom extends PseudoRandom {
        private AtomicInteger seed;
        AtomicPseudoRandom(int seed) {
            this.seed = new AtomicInteger(seed);
        }
    
        public int nextInt(int n) {
            while (true) {
                int s = seed.get();
                int nextSeed = calculateNext(s);
                if (seed.compareAndSet(s, nextSeed)) {
                    int remainder = s % n;
                    return remainder > 0 ? remainder : remainder + n;
                }
            }
        }
        ...
    }
    

    As you can see, it basically works almost the same way as incrementAndGet(), but performs arbitrary calculation (calculateNext()) instead of increment (and processes the result before return).

How I can use AtomicBoolean and what is that class for?

The AtomicBoolean class gives you a boolean value that you can update atomically. Use it when you have multiple threads accessing a boolean variable.

The java.util.concurrent.atomic package overview gives you a good high-level description of what the classes in this package do and when to use them. I'd also recommend the book Java Concurrency in Practice by Brian Goetz.

Is there any condition where finally might not run in java? Thanks.

Here are some conditions which can bypass a finally block:

  1. If the JVM exits while the try or catch code is being executed, then the finally block may not execute.
  2. Normal Shutdown - this occurs either when the last non-daemon thread exits OR when Runtime.exit()
  3. When a thread exits, the JVM performs an inventory of running threads, and if the only threads that are left are daemon threads, it initiates an orderly shutdown. When the JVM halts, any remaining daemon threads are abandoned finally blocks are not executed, stacks are not unwound the JVM just exits. Daemon threads should be used sparingly few processing activities can be safely abandoned at any time with no cleanup. In particular, it is dangerous to use daemon threads for tasks that might perform any sort of I/O. Daemon threads are best saved for "housekeeping" tasks, such as a background thread that periodically removes expired entries from an in-memory cache.

Last non-daemon thread exits example:

public class TestDaemon {
    private static Runnable runnable = new Runnable() {
        @Override
        public void run() {
            try {
                while (true) {
                    System.out.println("Is alive");
                    Thread.sleep(10);
                    // throw new RuntimeException();
                }
            } catch (Throwable t) {
                t.printStackTrace();
            } finally {
                System.out.println("This will never be executed.");
            }
        }
    };

    public static void main(String[] args) throws InterruptedException {
        Thread daemon = new Thread(runnable);
        daemon.setDaemon(true);
        daemon.start();
        Thread.sleep(100);
        // daemon.stop();
        System.out.println("Last non-daemon thread exits.");
    }
}

Output:

Is alive
Is alive
Is alive
Is alive
Is alive
Is alive
Is alive
Is alive
Is alive
Is alive
Last non-daemon thread exits.
Is alive
Is alive
Is alive
Is alive
Is alive

I saw many code invoke the method Thread.currentThread.interrupt() in the catch block, why?

This is done to keep state.

When you catch the InterruptException and swallow it, you essentially prevent any higher level methods/thread groups from noticing the interrupt. Which may cause problems.

By calling Thread.currentThread().interrupt(), you set the interrupt flag of the thread, so higher level interrupt handlers will notice it and can handle it appropriately.

Java Concurrency in Practice discusses this in more detail in Chapter 7.1.3: Responding to Interruption. Its rule is:

Only code that implements a thread's interruption policy may swallow an interruption request. General-purpose task and library code should never swallow interruption requests.

Why is i++ not atomic in Java?

To get a bit deeper in Java I tried to count how often the loop in threads are executed.

So I used a

private static int total = 0;

in the main class.

I have two threads.

  • Thread 1: Prints System.out.println("Hello from Thread 1!");
  • Thread 2: Prints System.out.println("Hello from Thread 2!");

And I count the lines printed by thread 1 and thread 2. But the lines of thread 1 + lines of thread 2 don't match the total number of lines printed out.

Here is my code:

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.logging.Level;
import java.util.logging.Logger;

public class Test {

    private static int total = 0;
    private static int countT1 = 0;
    private static int countT2 = 0;
    private boolean run = true;

    public Test() {
        ExecutorService newCachedThreadPool = Executors.newCachedThreadPool();
        newCachedThreadPool.execute(t1);
        newCachedThreadPool.execute(t2);
        try {
            Thread.sleep(1000);
        }
        catch (InterruptedException ex) {
            Logger.getLogger(Test.class.getName()).log(Level.SEVERE, null, ex);
        }
        run = false;
        try {
            Thread.sleep(1000);
        }
        catch (InterruptedException ex) {
            Logger.getLogger(Test.class.getName()).log(Level.SEVERE, null, ex);
        }
        System.out.println((countT1 + countT2 + " == " + total));
    }

    private Runnable t1 = new Runnable() {
        @Override
        public void run() {
            while (run) {
                total++;
                countT1++;
                System.out.println("Hello #" + countT1 + " from Thread 2! Total hello: " + total);
            }
        }
    };

    private Runnable t2 = new Runnable() {
        @Override
        public void run() {
            while (run) {
                total++;
                countT2++;
                System.out.println("Hello #" + countT2 + " from Thread 2! Total hello: " + total);
            }
        }
    };

    public static void main(String[] args) {
        new Test();
    }
}

i++ is a statement which simply involves 3 operations:

  1. Read current value
  2. Write new value
  3. Store new value

These three operations are not meant to be executed in one step, in other words i++ is not a compound operation. As a result all sorts of things can go wrong when more than one threads are involved in a single but non-compound operation.

As an example imagine this scenario:

Time 1:

Thread A fetches i
Thread B fetches i

Time 2:

Thread A overwrites i with a new value say -foo-
Thread B overwrites i with a new value say -bar-
Thread B stores -bar- in i

// At this time thread B seems to be more 'active'. Not only does it overwrite 
// its local copy of i but also makes it in time to store -bar- back to 
// 'main' memory (i)

Time 3:

Thread A attempts to store -foo- in memory effectively overwriting the -bar- 
value (in i) which was just stored by thread B in Time 2.

Thread B has nothing to do here. Its work was done by Time 2. However it was 
all for nothing as -bar- was eventually overwritten by another thread.

And there you have it. A race condition.


That's why i++ is not atomic. If it was, none of this would have happened and each fetch-update-store would happen atomically. That's exactly what AtomicInteger is for and in your case it would probably fit right in.

P.S.

An excellent book covering all of those issues and then some is this: Java Concurrency in Practice

I'm writing a Java program which uses a lot of CPU because of the nature of what it does. However, lots of it can run in parallel, and I have made my program multi-threaded. When I run it, it only seems to use one CPU until it needs more then it uses another CPU - is there anything I can do in Java to force different threads to run on different cores/CPUs?

First, I'd suggest reading "Concurrency in Practice" by Brian Goetz.

alt text

This is by far the best book describing concurrent java programming.

Concurrency is 'easy to learn, difficult to master'. I'd suggest reading plenty about the subject before attempting it. It's very easy to get a multi-threaded program to work correctly 99.9% of the time, and fail 0.1%. However, here are some tips to get you started:

There are two common ways to make a program use more than one core:

  1. Make the program run using multiple processes. An example is Apache compiled with the Pre-Fork MPM, which assigns requests to child processes. In a multi-process program, memory is not shared by default. However, you can map sections of shared memory across processes. Apache does this with it's 'scoreboard'.
  2. Make the program multi-threaded. In a multi-threaded program, all heap memory is shared by default. Each thread still has it's own stack, but can access any part of the heap. Typically, most Java programs are multi-threaded, and not multi-process.

At the lowest level, one can create and destroy threads. Java makes it easy to create threads in a portable cross platform manner.

As it tends to get expensive to create and destroy threads all the time, Java now includes Executors to create re-usable thread pools. Tasks can be assigned to the executors, and the result can be retrieved via a Future object.

Typically, one has a task which can be divided into smaller tasks, but the end results need to be brought back together. For example, with a merge sort, one can divide the list into smaller and smaller parts, until one has every core doing the sorting. However, as each sublist is sorted, it needs to be merged in order to get the final sorted list. Since this is "divide-and-conquer" issue is fairly common, there is a JSR framework which can handle the underlying distribution and joining. This framework will likely be included in Java 7.

Anyone have a good rule of thumb for choosing between different implementations of Java Collection interfaces like List, Map, or Set?

For example, generally why or in what cases would I prefer to use a Vector or an ArrayList, a Hashtable or a HashMap?

About your first question...

List, Map and Set serve different purposes. I suggest reading about the Java Collections Framework at http://java.sun.com/docs/books/tutorial/collections/interfaces/index.html.

To be a bit more concrete:

  • use List if you need an array-like data structure and you need to iterate over the elements
  • use Map if you need something like a dictionary
  • use a Set if you only need to decide if something belongs to the set or not.

About your second question...

The main difference between Vector and ArrayList is that the former is synchronized, the latter is not synchronized. You can read more about synchronization in Java Concurrency in Practice.

The difference between Hashtable (note that the T is not a capital letter) and HashMap is similiar, the former is synchronized, the latter is not synchronized.

I would say that there are no rule of thumb for preferring one implementation or another, it really depends on your needs.

I wrote a below Singleton class. I am not sure whether this is thread safe singleton class or not?

public class CassandraAstyanaxConnection {

    private static CassandraAstyanaxConnection _instance;
    private AstyanaxContext<Keyspace> context;
    private Keyspace keyspace;
    private ColumnFamily<String, String> emp_cf;



    public static synchronized CassandraAstyanaxConnection getInstance() {
        if (_instance == null) {
            _instance = new CassandraAstyanaxConnection();
        }
        return _instance;
    }

    /**
     * Creating Cassandra connection using Astyanax client
     *
     */
    private CassandraAstyanaxConnection() {

        context = new AstyanaxContext.Builder()
        .forCluster(ModelConstants.CLUSTER)
        .forKeyspace(ModelConstants.KEYSPACE)
        .withAstyanaxConfiguration(new AstyanaxConfigurationImpl()      
            .setDiscoveryType(NodeDiscoveryType.RING_DESCRIBE)
        )
        .withConnectionPoolConfiguration(new ConnectionPoolConfigurationImpl("MyConnectionPool")
            .setPort(9160)
            .setMaxConnsPerHost(1)
            .setSeeds("127.0.0.1:9160")
        )
        .withAstyanaxConfiguration(new AstyanaxConfigurationImpl()      
            .setCqlVersion("3.0.0")
            .setTargetCassandraVersion("1.2"))
        .withConnectionPoolMonitor(new CountingConnectionPoolMonitor())
        .buildKeyspace(ThriftFamilyFactory.getInstance());

        context.start();
        keyspace = context.getEntity();

        emp_cf = ColumnFamily.newColumnFamily(
            ModelConstants.COLUMN_FAMILY, 
            StringSerializer.get(), 
            StringSerializer.get());
    }

    /**
     * returns the keyspace
     * 
     * @return
     */
    public Keyspace getKeyspace() {
        return keyspace;
    }

    public ColumnFamily<String, String> getEmp_cf() {
        return emp_cf;
    }
}

Can anyone help me with this? Any thoughts on my above Singleton class will be of great help.

Updated Code:-

I am trying to incorporate Bohemian suggestion in my code. Here is the updated code, I got-

public class CassandraAstyanaxConnection {
    private static class ConnectionHolder {
        static final CassandraAstyanaxConnection connection = new CassandraAstyanaxConnection();
    }
    public static CassandraAstyanaxConnection getInstance() {
        return ConnectionHolder.connection;
    }
    /**
     * Creating Cassandra connection using Astyanax client
     *
     */
    private CassandraAstyanaxConnection() {
        context = new AstyanaxContext.Builder()
        .forCluster(ModelConstants.CLUSTER)
        .forKeyspace(ModelConstants.KEYSPACE)
        .withAstyanaxConfiguration(new AstyanaxConfigurationImpl()      
        .setDiscoveryType(NodeDiscoveryType.RING_DESCRIBE)
                )
                .withConnectionPoolConfiguration(new ConnectionPoolConfigurationImpl("MyConnectionPool")
                .setPort(9160)
                .setMaxConnsPerHost(1)
                .setSeeds("127.0.0.1:9160")
                        )
                        .withAstyanaxConfiguration(new AstyanaxConfigurationImpl()      
                        .setCqlVersion("3.0.0")
                        .setTargetCassandraVersion("1.2"))
                        .withConnectionPoolMonitor(new CountingConnectionPoolMonitor())
                        .buildKeyspace(ThriftFamilyFactory.getInstance());
        context.start();
        keyspace = context.getEntity();
        emp_cf = ColumnFamily.newColumnFamily(
                ModelConstants.COLUMN_FAMILY, 
                StringSerializer.get(), 
                StringSerializer.get());
    }
    /**
     * returns the keyspace
     * 
     * @return
     */
    public Keyspace getKeyspace() {
        return keyspace;
    }
    public ColumnFamily<String, String> getEmp_cf() {
        return emp_cf;
    }
}

Can anyone take a look and let me know if this time I got it right or not?

Thanks for the help.

No, its not thread-safe if the values returned on the pulbic methods are changeble objects.

To this class be Thread-safe one way is to change it to be immutable.

To do that, you could change this methods like this:

public Keyspace getKeyspace() {
    // make a copy to prevent external user to modified or ensure that Keyspace is immutable, in that case, you don't have to make a copy
    return new Keyspace( keyspace );
}

public ColumnFamily<String, String> getEmp_cf() {
    // Same principle here. If ColumnFamily is immutable, you don't have to make a copy. If its not, then make a copy
    return new ColumnFamily( emp_cf );
}

In this book Java Concurrency in Practice you can see the principle of that immutability.

I am still pretty new to the concept of threading, and try to understand more about it. Recently, I came across a blog post on What Volatile Means in Java by Jeremy Manson, where he writes:

When one thread writes to a volatile variable, and another thread sees that write, the first thread is telling the second about all of the contents of memory up until it performed the write to that volatile variable. [...] all of the memory contents seen by Thread 1, before it wrote to [volatile] ready, must be visible to Thread 2, after it reads the value true for ready. [emphasis added by myself]

Now, does that mean that all variables (volatile or not) held in Thread 1's memory at the time of the write to the volatile variable will become visible to Thread 2 after it reads that volatile variable? If so, is it possible to puzzle that statement together from the official Java documentation/Oracle sources? And from which version of Java onwards will this work?

In particular, if all Threads share the following class variables:

private String s = "running";
private volatile boolean b = false;

And Thread 1 executes the following first:

s = "done";
b = true;

And Thread 2 then executes afterwards (after Thread 1 wrote to the volatile field):

boolean flag = b; //read from volatile
System.out.println(s);

Would this be guaranteed to print "done"?

What would happen if instead of declaring b as volatile I put the write and read into a synchronized block?

Additionally, in a discussion entitled "Are static variables shared between threads?", @TREE writes:

Don't use volatile to protect more than one piece of shared state.

Why? (Sorry; I can't comment yet on other questions, or I would have asked there...)

Would this be guaranteed to print "done"?

As said in Java Concurrency in Practice:

When thread A writes to a volatile variable and subsequently thread B reads that same variable, the values of all variables that were visible to A prior to writing to the volatile variable become visible to B after reading the volatile variable.

So YES, This guarantees to print "done".

What would happen if instead of declaring b as volatile I put the write and read into a synchronized block?

This too will guarantee the same.

Don't use volatile to protect more than one piece of shared state.

Why?

Because, volatile guarantees only Visibility. It does'nt guarantee atomicity. If We have two volatile writes in a method which is being accessed by a thread A and another thread B is accessing those volatile variables , then while thread A is executing the method it might be possible that thread A will be preempted by thread B in the middle of operations(e.g. after first volatile write but before second volatile write by the thread A). So to guarantee the atomicity of operation synchronization is the most feasible way out.

I saw some examples in java where they do synchronization on a block of code to change some variable while that variable was declared volatile originally .. I saw that in an example of singleton class where they declared the unique instance as volatile and they sychronized the block that initializes that instance ... My question is why we declare it volatile while we synch on it, why we need to do both?? isn't one of them is sufficient for the other ??

public class someClass {
volatile static uniqueInstance = null;

public static someClass getInstance() {
        if(uniqueInstance == null) {
            synchronized(someClass.class) {
                if(uniqueInstance == null) {
                    uniqueInstance = new someClass();
                }
            }
        }
        return uniqueInstance;
    }

thanks in advance.

This post explains the idea behind volatile.

It is also addressed in the seminal work, Java Concurrency in Practice.

The main idea is that concurrency not only involves protection of shared state but also the visibility of that state between threads: this is where volatile comes in. (This larger contract is defined by the Java Memory Model.)

For years and years, I've tried to understand the part of Java specification that deals with memory model and concurrency. I have to admit that I've failed miserably. Yes' I understand about locks and "synchronized" and wait() and notify(). And I can use them just fine, thank you. I even have a vague idea about what "volatile" does. But all of that was not derived from the language spec - rather from general experience.

Here are two sample questions that I am asking. I am not so much interested in particular answers, as I need to understand how the answers are derived from the spec (or may be how I conclude that the spec has no answer).

  • What does "volatile" do, exactly?
  • Are writes to variable atomic? Does it depend on variable's type?

I wont try to explain these issues here but instead refer you to Brian Goetz excellent book on the subject.

The book is "Java Concurrency in Practice", can be found at Amazon or any other well sorted store for computer literature.

I'm not going to attempt to actually answer your questions here - instead I'll redirect you to the book which I seeing recommended for advice on this topic: Java Concurrency in Practice.

One word of warning: if there are answers here, expect quite a few of them to be wrong. One of the reasons I'm not going to post details is because I'm pretty sure I'd get it wrong in at least some respects. I mean no disrespect whatsoever to the community when I say that the chances of everyone who thinks they can answer this question actually having enough rigour to get it right is practically zero. (Joe Duffy recently found a bit of the .NET memory model that was surprised by. If he can get it wrong, so can mortals like us.)


I will offer some insight on just one aspect, because it's often misunderstood:

There's a difference between volatility and atomicity. People often think that an atomic write is volatile (i.e. you don't need to worry about the memory model if the write is atomic). That's not true.

Volatility is about whether one thread performing a read (logically, in the source code) will "see" changes made by another thread.

Atomicity is about whether there is any chance that if a change is seen, only part of the change will be seen.

For instance, take writing to an integer field. That is guaranteed to be atomic, but not volatile. That means that if we have (starting at foo.x = 0):

Thread 1: foo.x = 257;
Thread 2: int y = foo.x;

It's possible for y to be 0 or 257. It won't be any other value, (e.g. 256 or 1) due to the atomicity constraint. However, even if you know that in "wall time" the code in thread 2 executed after the code in thread 1, there could be odd caching, memory accesses "moving" etc. Making the variable x volatile will fix this.

I'll leave the rest up to real honest-to-goodness experts.

I am applying my new found knowledge of threading everywhere and getting lots of surprises

Example:

I used threads to add numbers in an array. And outcome was different every time. The problem was that all of my threads were updating the same variable and were not synchronized.

  • What are some known thread issues?
  • What care should be taken while using threads?
  • What are good multithreading resources.
  • Please provide examples.

sidenote:
(I renamed my program thread_add.java to thread_random_number_generator.java:-)

I notice you are writing in java and that nobody else mentioned books so Java Concurrency In Practice should be your multi-threaded bible.

The following piece of code tries to accompolish this.

The code loops forever and checks if there are any pending requests to be processed. If there is any, it creates a new thread to process the request and submits it to the executor. Once all the threads are done,it sleeps for 60 seconds and again checks for pending requests.

public static void main(String a[]){
    //variables init code omitted
    ExecutorService service = Executors.newFixedThreadPool(15);
    ExecutorCompletionService<Long> comp = new ExecutorCompletionService<Long>(service);
    while(true){
        List<AppRequest> pending = service.findPendingRequests();
        int noPending = pending.size();
        if (noPending > 0) {
            for (AppRequest req : pending) {
                Callable<Long> worker = new RequestThread(something, req);
                comp.submit(worker);
            }
        }
        for (int i = 0; i < noPending; i++) {
            try {
                Future<Long> f = comp.take();
                long name;
                try {
                    name = f.get();
                    LOGGER.debug(name + " got completed");
                } catch (ExecutionException e) {
                    LOGGER.error(e.toString());
                }
            } catch (InterruptedException e) {
                LOGGER.error(e.toString());
            }
        }
        TimeUnit.SECONDS.sleep(60);
    }

  }

My question is most of the processing done by these threads deal with database. And this program will run on a windows machine. What happens to these threads when someone tries to shutdown or logoff the machine.? How to gracefully shutdown the running threads and also the executor.?

The book "Java Concurrency in Practice" states:

7.4. JVM Shutdown

The JVM can shut down in either an orderly or abrupt manner. An orderly shutdown is initiated when the last "normal" (nondaemon) thread terminates, someone calls System.exit, or by other platform-specific means (such as sending a SIGINT or hitting Ctrl-C). [...]

7.4.1. Shutdown Hooks

In an orderly shutdown, the JVM first starts all registered shutdown hooks. Shutdown hooks are unstarted threads that are registered with Runtime.addShutdownHook. The JVM makes no guarantees on the order in which shutdown hooks are started. If any application threads (daemon or nondaemon) are still running at shutdown time, they continue to run concurrently with the shutdown process. When all shutdown hooks have completed, the JVM may choose to run finalizers if runFinalizersOnExit is true, and then halts. The JVM makes no attempt to stop or interrupt any application threads that are still running at shutdown time; they are abruptly terminated when the JVM eventually halts. If the shutdown hooks or finalizers don't complete, then the orderly shutdown process "hangs" and the JVM must be shut down abruptly. [...]

The important bits are, "The JVM makes no attempt to stop or interrupt any application threads that are still running at shutdown time; they are abruptly terminated when the JVM eventually halts." so I suppose the connection to the DB will abruptly terminate, if no shutdown hooks are there to do a graceful clean up (if you are using frameworks, they usually do provide such shutdown hooks). In my experience, session to the DB can remain until it is timed out by the DB, etc. when the app. is terminated without such hooks.

Suppose I have a static complex object that gets periodically updated by a pool of threads, and read more or less continually in a long-running thread. The object itself is always immutable and reflects the most recent state of something.

class Foo() { int a, b; }
static Foo theFoo;
void updateFoo(int newA, int newB) {
  f = new Foo();
  f.a = newA;
  f.b = newB;
  // HERE
  theFoo = f;
}
void readFoo() {
  Foo f = theFoo;
  // use f...
}

I do not care in the least whether my reader sees the old or the new Foo, however I need to see a fully initialized object. IIUC, The Java spec says that without a memory barrier in HERE, I may see an object with f.b initialized but f.a not yet committed to memory. My program is a real-world program that will sooner or later commit stuff to memory, so I don't need to actually commit the new value of theFoo to memory right away (though it wouldn't hurt).

What do you think is the most readable way to implement the memory barrier ? I am willing to pay a little performance price for the sake of readability if need be. I think I can just synchronize the assignment to Foo and that would work, but I'm not sure it's very obvious to someone reading the code why I do that. I could also synchronize the whole initialization of the new Foo, but that would introduce more locking that actually needed.

How would you write it so that it's as readable as possible ?
Bonus kudos for a Scala version :)

Short Answers to the Original Question

  • If Foo is immutable, simply making the fields final will ensure complete initialization and consistent visibility of fields to all threads irrespective of synchronization.
  • Whether or not Foo is immutable, publication via volatile theFoo or AtomicReference<Foo> theFoo is sufficient to ensure that writes to its fields are visible to any thread reading via theFoo reference
  • Using a plain assignment to theFoo, reader threads are never guaranteed to see any update
  • In my opinion, and based on JCiP, the "most readable way to implement the memory barrier" is AtomicReference<Foo>, with explicit synchronization coming in second, and use of volatile coming in third
  • Sadly, I have nothing to offer in Scala

You can use volatile

I blame you. Now I'm hooked, I've broken out JCiP, and now I'm wondering if any code I've ever written is correct. The code snippet above is, in fact, potentially inconsistent. (Edit: see the section below on Safe publication via volatile.) The reading thread could also see stale (in this case, whatever the default values for a and b were) for unbounded time. You can do one of the following to introduce a happens-before edge:

  • Publish via volatile, which creates a happens-before edge equivalent to a monitorenter (read side) or monitorexit (write side)
  • Use final fields and initialize the values in a constructor before publication
  • Introduce a synchronized block when writing the new values to theFoo object
  • Use AtomicInteger fields

These gets the write ordering solved (and solves their visibility issues). Then you need to address visibility of the new theFoo reference. Here, volatile is appropriate -- JCiP says in section 3.1.4 "Volatile variables", (and here, the variable is theFoo):

You can use volatile variables only when all the following criteria are met:
  • Writes to the variable do not depend on its current value, or you can ensure that only a single thread ever updates the value;
  • The variable does not participate in invariants with other state variables; and
  • Locking is not required for any other reason while the variable is being accessed

If you do the following, you're golden:

class Foo { 
  // it turns out these fields may not be final, with the volatile publish, 
  // the values will be seen under the new JMM
  final int a, b; 
  Foo(final int a; final int b) 
  { this.a = a; this.b=b; }
}

// without volatile here, separate threads A' calling readFoo()
// may never see the new theFoo value, written by thread A 
static volatile Foo theFoo;
void updateFoo(int newA, int newB) {
  f = new Foo(newA,newB);
  theFoo = f;
}
void readFoo() {
  final Foo f = theFoo;
  // use f...
}

Straightforward and Readable

Several folks on this and other threads (thanks @John V) note that the authorities on these issues emphasize the importance of documentation of synchronization behavior and assumptions. JCiP talks in detail about this, provides a set of annotations that can be used for documentation and static checking, and you can also look at the JMM Cookbook for indicators about specific behaviors that would require documentation and links to the appropriate references. Doug Lea has also prepared a list of issues to consider when documenting concurrency behavior. Documentation is appropriate particularly because of the concern, skepticism, and confusion surrounding concurrency issues (on SO: "Has java concurrency cynicism gone too far?"). Also, tools like FindBugs are now providing static checking rules to notice violations of JCiP annotation semantics, like "Inconsistent Synchronization: IS_FIELD-NOT_GUARDED".

Until you think you have a reason to do otherwise, it's probably best to proceed with the most readable solution, something like this (thanks, @Burleigh Bear), using the @Immutable and @GuardedBy annotations.

@Immutable
class Foo { 
  final int a, b; 
  Foo(final int a; final int b) { this.a = a; this.b=b; }
}

static final Object FooSync theFooSync = new Object();

@GuardedBy("theFooSync");
static Foo theFoo;

void updateFoo(final int newA, final int newB) {
  f = new Foo(newA,newB);
  synchronized (theFooSync) {theFoo = f;}
}
void readFoo() {
  final Foo f;
  synchronized(theFooSync){f = theFoo;}
  // use f...
}

or, possibly, since it's cleaner:

static AtomicReference<Foo> theFoo;

void updateFoo(final int newA, final int newB) {
  theFoo.set(new Foo(newA,newB)); }
void readFoo() { Foo f = theFoo.get(); ... }

When is it appropriate to use volatile

First, note that this question pertains to the question here, but has been addressed many, many times on SO:

In fact, a google search: "site:stackoverflow.com +java +volatile +keyword" returns 355 distinct results. Use of volatile is, at best, a volatile decision. When is it appropriate? The JCiP gives some abstract guidance (cited above). I'll collect some more practical guidelines here:

  • I like this answer: "volatile can be used to safely publish immutable objects", which neatly encapsulates most of the range of use one might expect from an application programmer.
  • @mdma's answer here: "volatile is most useful in lock-free algorithms" summarizes another class of uses—special purpose, lock-free algorithms which are sufficiently performance sensitive to merit careful analysis and validation by an expert.

  • Safe Publication via volatile

    Following up on @Jed Wesley-Smith, it appears that volatile now provides stronger guarantees (since JSR-133), and the earlier assertion "You can use volatile provided the object published is immutable" is sufficient but perhaps not necessary.

    Looking at the JMM FAQ, the two entries How do final fields work under the new JMM? and What does volatile do? aren't really dealt with together, but I think the second gives us what we need:

    The difference is that it is now no longer so easy to reorder normal field accesses around them. Writing to a volatile field has the same memory effect as a monitor release, and reading from a volatile field has the same memory effect as a monitor acquire. In effect, because the new memory model places stricter constraints on reordering of volatile field accesses with other field accesses, volatile or not, anything that was visible to thread A when it writes to volatile field f becomes visible to thread B when it reads f.

    I'll note that, despite several rereadings of JCiP, the relevant text there didn't leap out to me until Jed pointed it out. It's on p. 38, section 3.1.4, and it says more or less the same thing as this preceding quote -- the published object need only be effectively immutable, no final fields required, QED.

    Older stuff, kept for accountability

    One comment: Any reason why newA and newB can't be arguments to the constructor? Then you can rely on publication rules for constructors...

    Also, using an AtomicReference likely clears up any uncertainty (and may buy you other benefits depending on what you need to get done in the rest of the class...) Also, someone smarter than me can tell you if volatile would solve this, but it always seems cryptic to me...

    In further review, I believe that the comment from @Burleigh Bear above is correct --- (EDIT: see below) you actually don't have to worry about out-of-sequence ordering here, since you are publishing a new object to theFoo. While another thread could conceivably see inconsistent values for newA and newB as described in JLS 17.11, that can't happen here because they will be committed to memory before the other thread gets ahold of a reference to the new f = new Foo() instance you've created... this is safe one-time publication. On the other hand, if you wrote

    void updateFoo(int newA, int newB) {
      f = new Foo(); theFoo = f;     
      f.a = newA; f.b = newB;
    }
    

    But in that case the synchronization issues are fairly transparent, and ordering is the least of your worries. For some useful guidance on volatile, take a look at this developerWorks article.

    However, you may have an issue where separate reader threads can see the old value for theFoo for unbounded amounts of time. In practice, this seldom happens. However, the JVM may be allowed to cache away the value of the theFoo reference in another thread's context. I'm quite sure marking theFoo as volatile will address this, as will any kind of synchronizer or AtomicReference.

    How do threads that rely on one another communicate in Java?

    For example, I am building a web crawler with threads that need data that comes from other threads.

    That depends on the nature of the communication.

    • Is it duplex (ie A talks to B and B talks to A)?
    • Is it communication of data or communication of completion?
    • and so on.

    The simplest and most advisable form of inter-thread communication is simply to wait for the completion of other threads. That's most easily done by using Future:

    ExecutorService exec = Executors.newFixedThreadPool(50);
    final Future f = exec.submit(task1);
    exec.submit(new Runnable() {
        @Override
        public void run() {
            f.get();
            // do stuff
        }
    });
    

    The second task won't execute until the first completes.

    Java 5+ has many concurrent utilities for dealing with this kind of thing. This could mean using LinkedBlockingQueues, CountDownLatch or many, many others.

    For an in-depth examination of concurrency Java Concurrency in Practice is a must-read.

    Many people at SO adviced to dive into Java concurrency by reading Java Concurrency in Practice (JCIP), sometimes Doug Lea's book of 1999 is mentioned as well:

    After reading JCIP, still feel the need for recapitulation/consolidation of the topic. This mainly because I feel the lack of examples in JCIP, however the book touches almost all aspects of Java multithreading.

    Can you recommend any book / resources that would supplement JCIP by lots of examples of java.util.concurrent.* usage?

    Any advice or links are welcome. Thanks a lot.

    We have developed an Android Application which involves a service in the background. To implement this background service we have used IntentService. We want the application to poll the server every 60 seconds. So in the IntentService, the server is polled in a while loop. At the end of the while loop we have used Thread.sleep(60000) so that the next iteration starts only after 60 seconds.
    But in the Logcat, I see that sometimes it takes the application more than 5 minutes to wake up (come out of that sleep and start the next iteration). It is never 1 minute as we want it to be.

    What is the reason for this? Should background Services be implemented in a different way?

    Problem2

    Android kills this background process (intent service) after sometime. Can't exactly say when. But sometimes its hours and sometimes days before the background service gets killed. I would appreciate it if you would tell me the reason for this. Because Services are not meant to be killed. They are meant to run in background as long as we want it to.

    Code :

    @Override
     protected void onHandleIntent(Intent intent) {
      boolean temp=true;
      while(temp==true) {
        try {
          //connect to the server 
          //get the data and store it in the sqlite data base
        }
        catch(Exception e) {
          Log.v("Exception", "in while loop : "+e.toString());
        }
        //Sleep for 60 seconds
        Log.v("Sleeping", "Sleeping");
        Thread.sleep(60000);
        Log.v("Woke up", "Woke up");
    
        //After this a value is extracted from a table
        final Cursor cur=db.query("run_in_bg", null, null, null, null, null, null);
        cur.moveToLast();
        String present_value=cur.getString(0);
        if(present_value==null) {
           //Do nothing, let the while loop continue  
        }
        else if( present_value.equals("false") || present_value.equals("False") ) {
           //break out of the while loop
           db.close();
           temp=false;
           Log.v("run_in_bg", "false");
           Log.v("run_in_bg", "exiting while loop");
           break;
        }
      }
    
    }
    

    But whenever the service is killed, it happens when the the process is asleep. The last log reads - Sleeping : Sleeping. Why does the service gets killed?

    You could use ScheduledExecutorService designed specifically for such purpose.

    Don't use Timers, as demonstrated in "Java Concurrency in Practice" they can be very inaccurate.

    Question How can I make sure my application is thread-safe? Are their any common practices, testing methods, things to avoid, things to look for?

    Background I'm currently developing a server application that performs a number of background tasks in different threads and communicates with clients using Indy (using another bunch of automatically generated threads for the communication). Since the application should be highly availabe, a program crash is a very bad thing and I want to make sure that the application is thread-safe. No matter what, from time to time I discover a piece of code that throws an exception that never occured before and in most cases I realize that it is some kind of synchronization bug, where I forgot to synchronize my objects properly. Hence my question concerning best practices, testing of thread-safety and things like that.

    mghie: Thanks for the answer! I should perhaps be a little bit more precise. Just to be clear, I know about the principles of multithreading, I use synchronization (monitors) throughout my program and I know how to differentiate threading problems from other implementation problems. But nevertheless, I keep forgetting to add proper synchronization from time to time. Just to give an example, I used the RTL sort function in my code. Looked something like

    FKeyList.Sort (CompareKeysFunc);
    

    Turns out, that I had to synchronize FKeyList while sorting. It just don't came to my mind when initially writing that simple line of code. It's these thins I wanna talk about. What are the places where one easily forgets to add synchronization code? How do YOU make sure that you added sync code in all important places?

    M2C - Java Concurrency in Practice is really good.

    I'm trying to get a handle on how to implement threading in a Java application that uses Spring for transaction management. I've found the TaskExecutor section in the Spring documentation, and ThreadPoolTaskExecutor looks like it would fit my needs;

    ThreadPoolTaskExecutor

    This implementation can only be used in a Java 5 environment but is also the most commonly used one in that environment. It exposes bean properties for configuring a java.util.concurrent.ThreadPoolExecutor and wraps it in a TaskExecutor. If you need something advanced such as a ScheduledThreadPoolExecutor, it is recommended that you use a ConcurrentTaskExecutor instead.

    However I have no idea how to go about using it. I've been searching for good examples for awhile now with no luck. If anyone can help me out I would appreciate it.

    Have a look through the Brian Goetz web site. His book Java Concurrency in Practice covers the java.util.concurrent package really well.

    Here's the deal. I have a hash map containing data I call "program codes", it lives in an object, like so:

    Class Metadata
    {
        private HashMap validProgramCodes;
        public HashMap getValidProgramCodes() { return validProgramCodes; }
        public void setValidProgramCodes(HashMap h) { validProgramCodes = h; }
    }
    

    I have lots and lots of reader threads each of which will call getValidProgramCodes() once and then use that hashmap as a read-only resource.

    So far so good. Here's where we get interesting.

    I want to put in a timer which every so often generates a new list of valid program codes (never mind how), and calls setValidProgramCodes.

    My theory -- which I need help to validate -- is that I can continue using the code as is, without putting in explicit synchronization. It goes like this: At the time that validProgramCodes are updated, the value of validProgramCodes is always good -- it is a pointer to either the new or the old hashmap. This is the assumption upon which everything hinges. A reader who has the old hashmap is okay; he can continue to use the old value, as it will not be garbage collected until he releases it. Each reader is transient; it will die soon and be replaced by a new one who will pick up the new value.

    Does this hold water? My main goal is to avoid costly synchronization and blocking in the overwhelming majority of cases where no update is happening. We only update once per hour or so, and readers are constantly flickering in and out.

    No, the code example is not safe, because there is no safe publication of any new HashMap instances. Without any synchronization, there is a possibility that a reader thread will see a partially initialized HashMap.

    Check out @erickson's explanation under "Reordering" in his answer. Also I can't recommend Brian Goetz's book Java Concurrency in Practice enough!

    Whether or not it is okay with you that reader threads might see old (stale) HashMap references, or might even never see a new reference, is beside the point. The worst thing that can happen is that a reader thread might obtain reference to and attempt to access a HashMap instance that is not yet initialized and not ready to be accessed.

    I'm midway through programming a Java program, and I'm at the stage where I'm debugging far more concurrency issues than I'd like to be dealing with.

    I have to ask: how do you deal with concurrency issues when setting out your program mentally? In my case, it's for a relatively simple game, yet issues with threads keep popping up - any quick-fix almost certainly leads to a new issue.

    Speaking in very general terms, what techniques should I use when deciding how my application should 'flow' with out all my threads getting in a knot?

    Read up on concurrency, or better yet take graduate-level course on concurrent programming if you are still in college. See The Java Tutorials: Lesson: Concurrency. One famous book for Java concurrency is Java Concurrency in Practice. Java has so much built into the framework to deal with concurrency issues, including concurrent collections and synchronized methods.

    Java Concurrency in Practice

    In what cases is it necessary to synchronize access to instance members? I understand that access to static members of a class always needs to be synchronized- because they are shared across all object instances of the class.

    My question is when would I be incorrect if I do not synchronize instance members?

    for example if my class is

    public class MyClass {
        private int instanceVar = 0;
    
        public setInstanceVar()
        {
            instanceVar++;
        }
    
        public getInstanceVar()
        {
            return instanceVar;
        }
    }
    

    in what cases (of usage of the class MyClass) would I need to have methods: public synchronized setInstanceVar() and public synchronized getInstanceVar() ?

    Thanks in advance for your answers.

    . Roughly, the answer is "it depends". Synchronizing your setter and getter here would only have the intended purpose of guaranteeing that multiple threads couldn't read variables between each others increment operations:

     synchronized increment()
     { 
           i++
     }
    
     synchronized get()
     {
       return i;
      }
    

    but that wouldn't really even work here, because to insure that your caller thread got the same value it incremented, you'd have to guarantee that you're atomically incrementing and then retrieving, which you're not doing here - i.e you'd have to do something like

      synchronized int {
        increment
        return get()
      }
    

    Basically, synchronization is usefull for defining which operations need to be guaranteed to run threadsafe (inotherwords, you can't create a situation where a separate thread undermines your operation and makes your class behave illogically, or undermines what you expect the state of the data to be). It's actually a bigger topic than can be addressed here.

    This book Java Concurrency in Practice is excellent, and certainly much more reliable than me.

    My Rails web app has dozens of methods from making calls to an API and processing query result. These methods have the following structure:

    def method_one
      batch_query_API
      process_data
    end
    ..........
    def method_nth
      batch_query_API
      process_data
    end
    
    def summary
      method_one
      ......
      method_nth
      collect_results
    end
    

    How can I run all query methods at the same time instead of sequential in Rails (without firing up multiple workers, of course)?

    Edit: all of the methods are called from a single instance variable. I think this limits the use of Sidekiq or Delay in submitting jobs simultaneously.

    Assuming that your problem is a slow external API, a solution could be the use of either threaded programming or asynchronous programming. By default when doing IO, your code will block. This basically means that if you have a method that does an HTTP request to retrieve some JSON your method will tell your operating system that you're going to sleep and you don't want to be woken up until the operating system has a response to that request. Since that can take several seconds, your application will just idly have to wait.

    This behavior is not specific to just HTTP requests. Reading from a file or a device such as a webcam has the same implications. Software does this to prevent hogging up the CPU when it obviously has no use of it.

    So the question in your case is: Do we really have to wait for one method to finish before we can call another? In the event that the behavior of method_two is dependent on the outcome of method_one, then yes. But in your case, it seems that they are individual units of work without co-dependence. So there is a potential for concurrency execution.

    You can start new threads by initializing an instance of the Thread class with a block that contains the code you'd like to run. Think of a thread as a program inside your program. Your Ruby interpreter will automatically alternative between the thread and your main program. You can start as been threads as you'd like, but the more threads you create, the longer turns your main program will have to wait before returning to execution. However, we are probably talking microseconds or less. Let's look at an example of threaded execution.

    def main_method
      Thread.new { method_one }
      Thread.new { method_two }
      Thread.new { method_three }
    end
    
    def method_one
      # something_slow_that_does_an_http_request
    end
    
    def method_two
      # something_slow_that_does_an_http_request
    end
    
    def method_three
      # something_slow_that_does_an_http_request
    end
    

    Calling main_method will cause all three methods to be executed in what appears to be parallel. In reality they are still being sequentually processed, but instead of going to sleep when method_one blocks, Ruby will just return to the main thread and switch back to method_one thread, when the OS has the input ready.

    Assuming each method takes two 2 ms to execute minus the wait for the response, that means all three methods are running after just 6 ms - practically instantly.

    If we assume that a response takes 500 ms to complete, that means you can cut down your total execution time from 2 + 500 + 2 + 500 + 2 + 500 to just 2 + 2 + 2 + 500 - in other words from 1506 ms to just 506 ms.

    It will feel like the methods are running simultanously, but in fact they are just sleeping simultanously.

    In your case however you have a challenge because you have an operation that is dependent on the completion of a set of previous operations. In other words, if you have task A, B, C, D, E and F, then A, B, C, D and E can be performed simultanously, but F cannot be performed until A, B, C, D and E are all complete.

    There are different ways to solve this. Let's look at a simple solution which is creating a sleepy loop in the main thread that periodically examines a list of return values to make sure some condition is fullfilled.

    def task_1
    # Something slow
    return results
    end
    
    def task_2
    # Something slow
    return results
    end
    
    def task_3
    # Something slow
    return results
    end
    
    my_responses = {}
    Thread.new { my_responses[:result_1] = task_1 }
    Thread.new { my_responses[:result_2] = task_2 }
    Thread.new { my_responses[:result_3] = task_3 }
    
    while (my_responses.count < 3) # Prevents the main thread from continuing until the three spawned threads are done and have dumped their results in the hash.
      sleep(0.1) # This will cause the main thread to sleep for 100 ms between each check. Without it, you will end up checking the response count thousands of times pr. second which is most likely unnecessary.
    end
    
    # Any code at this line will not execute until all three results are collected.
    

    Keep in mind that multithreaded programming is a tricky subject with numerous pitfalls. With MRI it's not so bad, because while MRI will happily switch between blocked threads, MRI doesn't support executing two threads simultanously and that solves quite a few concurrency concerns.

    If you want to get into multithreaded programming, I recommend this book: http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601

    It's centered around Java, but the pitfalls and concepts explained are universal.

    I am testing spawning off many threads running the same function on a 32 core server for Java and C#. I run the application with 1000 iterations of the function, which is batched across either 1,2,4,8, 16 or 32 threads using a threadpool.

    At 1, 2, 4, 8 and 16 concurrent threads Java is at least twice as fast as C#. However, as the number of threads increases, the gap closes and by 32 threads C# has nearly the same average run-time, but Java occasionally takes 2000ms (whereas both languages are usually running about 400ms). Java is starting to get worse with massive spikes in the time taken per thread iteration.

    EDIT This is Windows Server 2008

    EDIT2 I have changed the code below to show using the Executor Service threadpool. I have also installed Java 7.

    I have set the following optimisations in the hotspot VM:

    -XX:+UseConcMarkSweepGC -Xmx 6000

    but it still hasnt made things any better. The only difference between the code is that im using the below threadpool and for the C# version we use:

    http://www.codeproject.com/Articles/7933/Smart-Thread-Pool

    Is there a way to make the Java more optimised? Perhaos you could explain why I am seeing this massive degradation in performance?

    Is there a more efficient Java threadpool?

    (Please note, I do not mean by changing the test function)

    import java.io.DataOutputStream;
    import java.io.FileNotFoundException;
    import java.io.FileOutputStream;
    import java.io.PrintStream;
    import java.util.concurrent.ExecutorService;
    import java.util.concurrent.Executors;
    import java.util.concurrent.ThreadPoolExecutor;
    
    public class PoolDemo {
    
        static long FastestMemory = 2000000;
        static long SlowestMemory = 0;
        static long TotalTime;
        static int[] FileArray;
        static DataOutputStream outs;
        static FileOutputStream fout;
        static Byte myByte = 0;
    
      public static void main(String[] args) throws InterruptedException, FileNotFoundException {
    
            int Iterations = Integer.parseInt(args[0]);
            int ThreadSize = Integer.parseInt(args[1]);
    
            FileArray = new int[Iterations];
            fout = new FileOutputStream("server_testing.csv");
    
            // fixed pool, unlimited queue
            ExecutorService service = Executors.newFixedThreadPool(ThreadSize);
            ThreadPoolExecutor executor = (ThreadPoolExecutor) service;
    
            for(int i = 0; i<Iterations; i++) {
              Task t = new Task(i);
              executor.execute(t);
            }
    
            for(int j=0; j<FileArray.length; j++){
                new PrintStream(fout).println(FileArray[j] + ",");
            }
          }
    
      private static class Task implements Runnable {
    
        private int ID;
    
        public Task(int index) {
          this.ID = index;
        }
    
        public void run() {
            long Start = System.currentTimeMillis();
    
            int Size1 = 100000;
            int Size2 = 2 * Size1;
            int Size3 = Size1;
    
            byte[] list1 = new byte[Size1];
            byte[] list2 = new byte[Size2];
            byte[] list3 = new byte[Size3];
    
            for(int i=0; i<Size1; i++){
                list1[i] = myByte;
            }
    
            for (int i = 0; i < Size2; i=i+2)
            {
                list2[i] = myByte;
            }
    
            for (int i = 0; i < Size3; i++)
            {
                byte temp = list1[i];
                byte temp2 = list2[i];
                list3[i] = temp;
                list2[i] = temp;
                list1[i] = temp2;
            }
    
            long Finish = System.currentTimeMillis();
            long Duration = Finish - Start;
            TotalTime += Duration;
            FileArray[this.ID] = (int)Duration;
            System.out.println("Individual Time " + this.ID + " \t: " + (Duration) + " ms");
    
    
            if(Duration < FastestMemory){
                FastestMemory = Duration;
            }
            if (Duration > SlowestMemory)
            {
                SlowestMemory = Duration;
            }
        }
      }
    }
    

    Summary

    Below are the original response, update 1, and update 2. Update 1 talks about dealing with the race conditions around the test statistic variables by using concurrency structures. Update 2 is a much simpler way of dealing with the race condition issue. Hopefully no more updates from me - sorry for the length of the response but multithreaded programming is complicated!

    Original Response

    The only difference between the code is that im using the below threadpool

    I would say that is an absolutely huge difference. It's difficult to compare the performance of the two languages when their thread pool implementations are completely different blocks of code, written in user space. The thread pool implementation could have enormous impact on performance.

    You should consider using Java's own built-in thread pools. See ThreadPoolExecutor and the entire java.util.concurrent package of which it is part. The Executors class has convenient static factory methods for pools and is a good higher level interface. All you need is JDK 1.5+, though the newer, the better. The fork/join solutions mentioned by other posters are also part of this package - as mentioned, they require 1.7+.

    Update 1 - Addressing race conditions by using concurrency structures

    You have race conditions around the setting of FastestMemory, SlowestMemory, and TotalTime. For the first two, you are doing the < and > testing and then the setting in more than one step. This is not atomic; there is certainly the chance that another thread will update these values in between the testing and the setting. The += setting of TotalTime is also non-atomic: a test and set in disguise.

    Here are some suggested fixes.

    TotalTime

    The goal here is a threadsafe, atomic += of TotalTime.

    // At the top of everything
    import java.util.concurrent.atomic.AtomicLong;  
    
    ...    
    
    // In PoolDemo
    static AtomicLong TotalTime = new AtomicLong();    
    
    ...    
    
    // In Task, where you currently do the TotalTime += piece
    TotalTime.addAndGet (Duration); 
    

    FastestMemory / SlowestMemory

    The goal here is testing and updating FastestMemory and SlowestMemory each in an atomic step, so no thread can slip in between the test and update steps to cause a race condition.

    Simplest approach:

    Protect the testing and setting of the variables using the class itself as a monitor. We need a monitor that contains the variables in order to guarantee synchronized visibility (thanks @A.H. for catching this.) We have to use the class itself because everything is static.

    // In Task
    synchronized (PoolDemo.class) {
        if (Duration < FastestMemory) {
            FastestMemory = Duration;
        }
    
        if (Duration > SlowestMemory) {
            SlowestMemory = Duration;
        }
    }
    

    Intermediate approach:

    You may not like taking the whole class for the monitor, or exposing the monitor by using the class, etc. You could do a separate monitor that does not itself contain FastestMemory and SlowestMemory, but you will then run into synchronization visibility issues. You get around this by using the volatile keyword.

    // In PoolDemo
    static Integer _monitor = new Integer(1);
    static volatile long FastestMemory = 2000000;
    static volatile long SlowestMemory = 0;
    
    ...
    
    // In Task
    synchronized (PoolDemo._monitor) {
        if (Duration < FastestMemory) {
            FastestMemory = Duration;
        }
    
        if (Duration > SlowestMemory) {
            SlowestMemory = Duration;
        }
    }
    

    Advanced approach:

    Here we use the java.util.concurrent.atomic classes instead of monitors. Under heavy contention, this should perform better than the synchronized approach. Try it and see.

    // At the top of everything
    import java.util.concurrent.atomic.AtomicLong;    
    
    . . . . 
    
    // In PoolDemo
    static AtomicLong FastestMemory = new AtomicLong(2000000);
    static AtomicLong SlowestMemory = new AtomicLong(0);
    
    . . . . .
    
    // In Task
    long temp = FastestMemory.get();       
    while (Duration < temp) {
        if (!FastestMemory.compareAndSet (temp, Duration)) {
            temp = FastestMemory.get();       
        }
    }
    
    temp = SlowestMemory.get();
    while (Duration > temp) {
        if (!SlowestMemory.compareAndSet (temp, Duration)) {
            temp = SlowestMemory.get();
        }
    }
    

    Let me know what happens after this. It may not fix your problem, but the race condition around the very variables that track your performance is too dangerous to ignore.

    I originally posted this update as a comment but moved it here so that I would have room to show code. This update has been through a few iterations - thanks to A.H. for catching a bug I had in an earlier version. Anything in this update supersedes anything in the comment.

    Last but not least, an excellent source covering all this material is Java Concurrency in Practice, the best book on Java concurrency, and one of the best Java books overall.

    Update 2 - Addressing race conditions in a much simpler way

    I recently noticed that your current code will never terminate unless you add executorService.shutdown(). That is, the non-daemon threads living in that pool must be terminated or else the main thread will never exit. This got me to thinking that since we have to wait for all threads to exit, why not compare their durations after they finished, and thus bypass the concurrent updating of FastestMemory, etc. altogether? This is simpler and could be faster; there's no more locking or CAS overhead, and you are already doing an iteration of FileArray at the end of things anyway.

    The other thing we can take advantage of is that your concurrent updating of FileArray is perfectly safe, since each thread is writing to a separate cell, and since there is no reading of FileArray during the writing of it.

    With that, you make the following changes:

    // In PoolDemo
    // This part is the same, just so you know where we are
    for(int i = 0; i<Iterations; i++) {
        Task t = new Task(i);
        executor.execute(t);
    }
    
    // CHANGES BEGIN HERE
    // Will block till all tasks finish. Required regardless.
    executor.shutdown();
    executor.awaitTermination(10, TimeUnit.SECONDS);
    
    for(int j=0; j<FileArray.length; j++){
        long duration = FileArray[j];
        TotalTime += duration;
    
        if (duration < FastestMemory) {
            FastestMemory = duration;
        }
    
        if (duration > SlowestMemory) {
            SlowestMemory = duration;
        }
    
        new PrintStream(fout).println(FileArray[j] + ",");
    }
    
    . . . 
    
    // In Task
    // Ending of Task.run() now looks like this
    long Finish = System.currentTimeMillis();
    long Duration = Finish - Start;
    FileArray[this.ID] = (int)Duration;
    System.out.println("Individual Time " + this.ID + " \t: " + (Duration) + " ms");
    

    Give this approach a shot as well.

    You should definitely be checking your C# code for similar race conditions.

    Looks like I have messed up with Java Threads/OS Threads and Interpreted language.

    Before I begin, I do understand that Green Threads are Java Threads where the threading is taken care of by the JVM and the entire Java process runs only as a single OS Thread. Thereby on a multi processor system it is useless.

    Now my questions is. I have two Threads A and B. Each with 100 thousand lines of independent code. I run these threads in my Java Program on a multiprocessor system. Each Thread will be given a native OS Thread to RUN which can run on a different CPU but since Java is interpreted these threads will require to interact with the JVM again and again to convert the byte code to machine instructions ? Am I right ? If yes, than for smaller programs Java Threads wont be a big advantage ?

    Once the Hotspot compiles both these execution paths both can be as good as native Threads ? Am I right ?

    [EDIT] : An alternate question can be, assume you have a single Java Thread whose code is not JIT compiled, you create that Thread and start() it ? How does the OS Thread and JVM interact to run that Bytecode ?

    thanks

    Each Thread will be given a native OS Thread to RUN which can run on a different CPU but since Java is interpreted these threads will require to interact with the JVM again and again to convert the byte code to machine instructions ? Am I right ?

    You are mixing two different things; JIT done by the VM and the threading support offered by the VM. Deep down inside, everything you do translates to some sort of native code. A byte-code instruction which uses thread is no different than a JIT'ed code which accesses threads.

    If yes, than for smaller programs Java Threads wont be a big advantage ?

    Define small here. For short lived processes, yes, threading doesn't make that big a difference since your sequential execution is fast enough. Note that this again depends on the problem being solved. For UI toolkits, no matter how small the application, some sort of threading/asynchronous execution is required to keep the UI responsive.

    Threading also makes sense when you have things which can be run in parallel. A typical example would be doing heavy IO in on thread and computation in another. You really wouldn't want to block your processing just because your main thread is blocked doing IO.

    Once the Hotspot compiles both these execution paths both can be as good as native Threads ? Am I right ?

    See my first point.

    Threading really isn't a silver bullet, esp when it comes to the common misconception of "use threads to make this code go faster". A bit of reading and experience will be your best bet. Can I recommend getting a copy of this awesome book? :-)

    @Sanjay: Infact now I can reframe my question. If I have a Thread whose code has not been JIT'd how does the OS Thread execute it ?

    Again I'll say it, threading is a completely different concept from JIT. Let's try to look at the execution of a program in simple terms:

    java pkg.MyClass -> VM locates method to be run -> Start executing the byte-code for method line by line -> convert each byte-code instruction to its native counterpart -> instruction executed by OS -> instruction executed by machine

    When JIT has kicked in:

    java pkg.MyClass -> VM locates method to be run which has been JIT'ed -> locate the associated native code for that method -> instruction executed by OS -> instruction executed by machine

    As you can see, irrespective of the route you follow, the VM instruction has to be mapped to its native counterpart at some point in time. Whether that native code is stored for further re-use or thrown away if a different thing (optimization, remember?).

    Hence to answer your question, whenever you write threading code, it is translated to native code and run by the OS. Whether that translation is done on the fly or looked up at that point in time is a completely different issue.

    AtomicBoolean stores its value in:

    private volatile int value;
    

    Then, for example, extracting its value is done like this:

        public final boolean get() {
        return value != 0;
    }
    

    What is the reason behind it? Why boolean was not used?

    This probably is to be able to base several of the Atomic classes on the same base (Unsafe), which uses integer and provides the compare and swap operation.

    Concurrency in Practice provides a good explanation of the inner workings.

    Say I have two threads and an object. One thread assigns the object:

    public void assign(MyObject o) {
        myObject = o;
    }
    

    Another thread uses the object:

    public void use() {
        myObject.use();
    }
    

    Does the variable myObject have to be declared as volatile? I am trying to understand when to use volatile and when not, and this is puzzling me. Is it possible that the second thread keeps a reference to an old object in its local memory cache? If not, why not?

    Thanks a lot.

    I am trying to understand when to use volatile and when not

    You should mostly avoid using it. Use an AtomicReference instead (or another atomic class where appropriate). The memory effects are the same and the intent is much clearer.

    I highly suggest reading the excellent Java Concurrency in Practice for a better understanding.

    How do I make sure my java servlets web application is thread safe? What do I need to do in regards to session variables, static variables of a class, or anything else that could be a thread-safety problem?

    Wow, that's a loaded question.

    To put it simply, you need to ensure that access to any shared data is carefully synchronized. E.g., you may want to synchronize access to a static variable with a mutex or a synchronized function.

    Note that you may also need to synchronize at higher levels if you need atomic transactions that modify multiple shared resources at the same time.

    Designing a concurrent application is not simple, and there is no magic bullet (unfortunately). I highly recommend the book "Java Concurrency in Practice" for more information on writing safe concurrent code.

    I have a quadcore processor and I would really like to take advantage of all those cores when I'm running quick simulations. The problem is I'm only familiar with the small Linux cluster we have in the lab and I'm using Vista at home.

    What sort of things do I want to look into for multicore programming with C or Java? What is the lingo that I want to google?

    Thanks for the help.

    Check out this book: Java Concurrency in Practice

    Read that the following code is an example of "unsafe construction" as it allows this reference to escape. I couldn't quite get how 'this' escapes. I am pretty new to the java world. Can any one help me understand this.

    public class ThisEscape {
        public ThisEscape(EventSource source) {
            source.registerListener(
                new EventListener() {
                    public void onEvent(Event e) {
                        doSomething(e);
                    }
                });
        }
    }
    

    The example you have posted in your question comes from "Java Concurrency In Practice" by Brian Goetz et al. It is in section 3.2 "Publication and escape". I won't attempt to reproduce the details of that section here. (Go buy a copy for your bookshelf, or borrow a copy from your co-workers!)

    The problem illustrated by the example code is that the constructor allows the reference to the object being constructed to "escape" before the constructor finishes creating the object. This is a problem for two reasons:

    1. If the reference escapes, something can use the object before its constructor has completed the initialization and see it in an inconsistent (partly initialized) state. Even if the object escapes after initialization has completed, declaring a subclass can cause this to be violated.

    2. According to JLS 17.5, final attributes of an object can be used safely without synchronization. However, this is only true if the object reference is not published (does not escape) before its constructor finished. If you break this rule, the result is an insidious concurrency bug that might bite you when the code is executed on a multi-core / multi-processor machines.

    The ThisEscape example is sneaky because the reference is escaping via the this reference passed implicitly to the anonymous EventListener class constructor. However, the same problems will arise if the reference is explicitly published too soon.

    Here's an example to illustrate the problem of incompletely initialized objects:

    public class Thing {
        public Thing (Leaker leaker) {
            leaker.leak(this);
        }
    }
    
    public class NamedThing  extends Thing {
        private String name;
    
        public NamedThing (Leaker leaker, String name) {
            super(leaker);
    
        }
    
        public String getName() {
            return name; 
        }
    }
    

    If the Leaker.leak(...) method calls getName() on the leaked object, it will get null ... because at that point in time the object's constructor chain has not completed.

    Here's an example to illustrate the unsafe publication problem for final attributes.

    public class Unsafe {
        public final int foo = 42;
        public Unsafe(Unsafe[] leak) {
            leak[0] = this;   // Unsafe publication
            // Make the "window of vulnerability" large
            for (long l = 0; l < /* very large */ ; l++) {
                ...
            }
        }
    }
    
    public class Main {
        public static void main(String[] args) {
            final Unsafe[] leak = new Unsafe[1];
            new Thread(new Runnable() {
                public void run() {
                    Thread.yield();   // (or sleep for a bit)
                    new Unsafe(leak);
                }
            }).start();
    
            while (true) {
                if (leak[0] != null) {
                    if (leak[0].foo == 42) {
                        System.err.println("OK");
                    } else {
                        System.err.println("OUCH!");
                    }
                    System.exit(0);
                }
            }
        }
    }
    

    Some runs of this application may print "OUCH!" instead of "OK", indicating that the main thread has observed the Unsafe object in an "impossible" state due to unsafe publication via the leak array. Whether this happens or not will depend on your JVM and your hardware platform.

    Now this example is clearly artificial, but it is not difficult to imagine how this kind of thing can happen in real multi-threaded applications.

    I just had the exact same question while reading "Java Concurrency In Practice" by Brian Goetz.

    Stephen C's answer (the accepted one) is excellent! I only wanted to add on top of that one more resource I discovered. It is from JavaSpecialists, where Dr. Heinz M. Kabutz analyzes exactly the code example that devnull posted. He explains what classes are generated (outer, inner) after compiling and how this escapes. I found that explanation useful so I felt like sharing :)

    issue192 (where he extends the example and provides a race condition.)

    issue192b (where he explains what kind of classes are generated after compiling and how this escapes.)

    I have a program that continually polls the database for change in value of some field. It runs in the background and currently uses a while(true) and a sleep() method to set the interval. I am wondering if this is a good practice? And, what could be a more efficient way to implement this? The program is meant to run at all times.

    Consequently, the only way to stop the program is by issuing a kill on the process ID. The program could be in the middle of a JDBC call. How could I go about terminating it more gracefully? I understand that the best option would be to devise some kind of exit strategy by using a flag that will be periodically checked by the thread. But, I am unable to think of a way/condition of changing the value of this flag. Any ideas?

    This is really too big an issue to answer completely in this format. Do yourself a favour and go buy Java Concurrency in Practice. There is no better resource for concurrency on the Java 5+ platform out there. There are whole chapters devoted to this subject.

    On the subject of killing your process during a JDBC call, that should be fine. I believe there are issues with interrupting a JDBC call (in that you can't?) but that's a different issue.

    I've just started looking at Java's Executors class and the newCachedThreadPool( ) method. According to the API, the resulting thread pool reuses existing Thread objects for new tasks.

    I'm a bit puzzled how this is implemented because I couldn't find any method in the Thread API that lets you set the behaviour of an existing Thread object.

    For example, you can create a new Thread from a Runnable object, which makes the Thread call the Runnable's run( ) method. However, there is no setter method in the Thread API that takes a Runnable as an argument.

    I'd appreciate any pointers.

    The threadpool has threads that look for runnable jobs. Instead of starting a new thread from the Runnable the thread will just call the function run(). So a thread in a ThreadPool isn't created with the Runnable you provide,but with one that just checks if any tasks are ready to be executed and calls them directly.

    So it would look something like this:

    while(needsToKeepRunning()){
        if(hasMoreTasks()){
            getFirstTask().run();.
        }
        else
        {
            waitForOtherTasks();
        }
    }
    

    Of course this is overly simplified the real implementation with the waiting is much more elegant. A great source of information on how this really works can be found in Concurrency in Practice

    I've read various bits and pieces on concurrency, but was hoping to find a single resource that details and compares the various approaches. Ideally taking in threads, co-routines, message passing, actors, futures... whatever else that might be new that I don't know about yet!

    Would prefer a lay-coders guide than something overtly theoretical / mathematical.

    Thank you.

    I recommend An Introduction to Parallel Programming by Pacheco. It's clearly written, and a good intro to parallel programming.

    If you don't care about something being tied to a language, then Java Concurrency in Practice is a great resource.

    Oracle's online tutorial is free, but probably a bit more succinct than what you're looking for.


    That being said, the best teacher for concurrency is probably experience. I'd try to get some practice, myself. Start out by making a simulation of the Dining Philosophers problem. It's a classic.

    At first, let's see if you're interested in the topic or not. To grasp a big picture about concurrency, best practice is to take a look at operating systems books, like Operating systems internal by Stalings or Modern operating systems by Tanenbaum. They can give you an intuition about what this is all about.
    There's also an old book, named Concurent programming by Ben-Ari. If you found it, it can be helpful.

    Beside reading text books it's good make your hand dirty by writing some concurrent programs. Python is a very good choice if you want to start using threads. Every Python book has a part dedicated to this topic. Also a with a simple search on the web you can find a lot of resources about it, but I give these two higher preference:
    Multithreaded Programming (POSIX pthreads Tutorial), A very comprehensive introduction to concurrency and multi-threading. It's mainly about C multi-threading.
    The other one is Thread Synchronization Mechanisms in Python.

    Now if you still find your self interested about concurrent programming, it's time to go deeper. You almost have the basic knowledge of concurrency, now the best practice in this level is to start solving problem and become familiar with patterns. To achieve this goal, you can use The Little Book of Semaphores. It's one of best books in the field and it's also free. This is a book that can head you toward becoming a proficient.

    These should be enough if you want to approach concurrent programming, but if you have enough time, and you're eager, it's good to take a look at some other paradigms of concurrent programming, like actors which used in Erlang. I say it worth to read some chapters of the book Seven Languages in Seven Weeks. especially chapter about Erlang and IO. At first glance, it might be hard and strange, but it's good to become familiar with other solutions to concurrency.

    I wrote a server-client communication program and it worked well.

    client Module

    import java.io.*;
    import java.net.*;
    
    class Client {
        public static void main(String argv[]) throws Exception {
            String sentence;
            String modifiedSentence;
          while(true){
            BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in));
    
            Socket clientSocket = new Socket("myname.domain.com", 2343);
    
            DataOutputStream out = new DataOutputStream(clientSocket.getOutputStream());
            BufferedReader in = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));
    
            System.out.println("Ready");
            sentence = in.readLine();
            out.writeBytes(sentence + '\n');
            modifiedSentence = in.readLine();
            System.out.println(modifiedSentence);
           }
          clientSocket.close();
        }
    }
    

    Server Module

    import java.net.*;
    
    public class Server {
        public static void main(String args[]) throws Exception {
            String clientSentence;
            String cap_Sentence;
            ServerSocket my_Socket = new ServerSocket(2343);
    
            while(true) {
                Socket connectionSocket = my_Socket.accept();
                BufferedReader in = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream()));
                DataOutputStream out = new DataOutputStream(connectionSocket.getOutputStream());
                clientSentence = in.readLine();
                cap_Sentence = "Raceived:" +  clientSentence + '\n';
                out.writeBytes(cap_Sentence);
            }
        }
    }
    

    The above is the code for single client - server communication, now I want multiple client to interact with that server.I googled for it and found that it can be done with the use of thread for each single client to talk to the server, but since I am a beginner I don't know exactly how to implement. So somebody please tell me how to do or give me some Idea about it.

    You want to look into Java concurrency. That's the concept of one Java program doing multiple things at once. At a high level you will be taking your while(true) { //... } block and running it as part of the run() method of a class implementing Runnable. You'll create instances of Thread that invoke that run() method, probably one per client you expect.

    For a really good, deep understanding of all that Java offers when it comes to concurrency, check out Java Concurrency in Practice.

    I've been ask to build a multi-threaded java application using the java.util.concurrent library. I'm not familiar with this library, but have a good understanding of problems with multi-threaded code.

    I'm looking for a tutorial and example code that shows this java library in use and it's best practises.

    If you are a fast learner, I recommend the site www.java2s.com (Java API by Example).

    Here's the full link for the concurrent package: http://www.java2s.com/Code/JavaAPI/java.util.concurrent/Catalogjava.util.concurrent.htm

    EDIT: If you can spend some cash (and isn't in a hurry), I recommend this book: Java Concurrency in Practice http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601/ref=sr_1_1?ie=UTF8&qid=1290021702&sr=8-1

    It is really full of examples and good practices.

    I've been playing with functional programming lately and there are pretty good treatments on the topic of side effects, why they should be contained, etc. In projects where OOP is used, I'm looking for some resources which lay out some strategies for minimizing side effect and/or state.

    A good example of this is the book RESTful Web Services which gives you strategies for minimizing state in a web application. What others exist?

    Remember I'm not looking for another OOP analysts/design patterns book (though good encapsulation and loose coupling help avoid side effects) but rather a resource where the topic itself is state/side effects.

    Some compiled answers

    • OOP programmers who mostly care about state do so because of concurrency, so read Java Concurrency in Practice. [exactly what I was looking for]
    • Use TDD to make side effects more visible [I like it, example: the bigger your setUps are, the more state you need in place to run your tests = good warning]
    • Command-query separation [Good stuff, prevents the side effect of changing a function argument which is generally confusing]
    • Methods do only one thing, perhaps use descriptive names if they change the state of their object so it's simple and clear.
    • Make objects immutable [I really like this]
    • Pass values as parameters, instead of storing them in member variables. [I don't link this; it clutters up function prototype and is actively discouraged by Clean Code and other books, though I do admit it helps the state issue]
    • Recompute values instead of storing and updating them [I also really like this; in the apps I work on performance is a minor concern]
    • Similarly, don't copy state around if you can avoid it. Make one object responsible for keeping it and let others access it there. [Basic OOP principle, good advice]

    I don't think you'll find a lot current material in the OO world on this topic, simply because OOP (and most imperative programming, for that matter) relies on state and side effects. Consider logging, for instance. It's pure side-effect, yet in any self-respecting J2EE app, it's everywhere. Hoare's original QuickSort relies on mutable state, since you have to swap values around a pivot, and yet it too is everywhere.

    This is why many OO programmers have trouble wrapping their heads around functional programming paradigms. They try to reassign the value of "x," discover that it can't be done (at least not in the way it can in every other language they've worked in), and they throw up their hands and shout "This is impossible!" Eventually, if they're patient, they learn recursion and currying and how the map function replaces the need for loops, and they calm down. But the learning curve can be very steep for some.

    The OO programmers these days who care most about avoiding state are those working on concurrency. The reasons for this are obvious -- mutable state and side effects cause huge headaches when you're trying to manage concurrency between threads. As a result, the best discussion I've seen in the OO world about avoiding state is Java Concurrency in Practice.

    The question I am asking is related to StringBuilder and StringBuffer in Java but not the same. I want to see what really happens if a StringBuilder is modified by two threads at the same time.

    I wrote the following classes:

    public class ThreadTester
    {
        public static void main(String[] args) throws InterruptedException
        {
            Runnable threadJob = new MyRunnable();
            Thread myThread = new Thread(threadJob);
            myThread.start();
    
            for (int i = 0; i < 100; i++)
            {
                Thread.sleep(10);
                StringContainer.addToSb("a");
            }
    
            System.out.println("1: " + StringContainer.getSb());
            System.out.println("1 length: " + StringContainer.getSb().length());
        }
    }
    
    public class MyRunnable implements Runnable
    {
        @Override
        public void run()
        {
            for (int i = 0; i < 100; i++)
            {
                try
                {
                    Thread.sleep(10);
                }
                catch (InterruptedException e)
                {
                    e.printStackTrace();
                }
                StringContainer.addToSb("b");
            }
    
            System.out.println("2: " + StringContainer.getSb());
            System.out.println("2 length: " + StringContainer.getSb().length());
        }
    }
    
    public class StringContainer
    {
        private static final StringBuffer sb = new StringBuffer();
    
        public static StringBuffer getSb()
        {
            return sb;
        }
    
        public static void addToSb(String s)
        {
            sb.append(s);
        }
    }
    

    Initially I kept a StringBuffer in the StringContainer. Since StringBuffer is thread-safe, at a time, only one thread can append to it, so the output is consistent - either both threads reported the length of the buffer as 200, like:

    1: abababababababababbaabababababababbaababababababababababababbabaabbababaabbaababababbababaabbababaabababbaabababbababababaababababababababbababaabbaababbaababababababbaababbababaababbabaabbababababaab
    1 length: 200
    2: abababababababababbaabababababababbaababababababababababababbabaabbababaabbaababababbababaabbababaabababbaabababbababababaababababababababbababaabbaababbaababababababbaababbababaababbabaabbababababaab
    2 length: 200
    

    or one of them reported 199 and the other 200, like:

    2: abbabababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababab
    2 length: 199
    1: abbababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababababa
    1 length: 200
    

    The key is that the last thread to complete reports a length of 200.

    Now, I changed StringContainer to have a StringBuilder instead of StringBuffer i.e.

    public class StringContainer
    {
        private static final StringBuilder sb = new StringBuilder();
    
        public static StringBuilder getSb()
        {
            return sb;
        }
    
        public static void addToSb(String s)
        {
            sb.append(s);
        }
    }
    

    I expect some of the writes to be over-written, which is happening. But the contents of the StringBuilder and the lengths do not match sometimes:

    1: ababbabababaababbaabbabababababaab
    1 length: 137
    2: ababbabababaababbaabbabababababaab
    2 length: 137
    

    As you can see the printed content has only 34 chars, but the length is 137. Why is this happening?

    @Extreme Coders - I just did one more test run:

    2: ababbabababaabbababaabbababaababaabbaababbaaababbaabbabbabbabababbabababbbabbbbbabababbaabababbabaabaaabaababbaabaababababbaabbbabbbbbababababbababaab
    1: ababbabababaabbababaabbababaababaabbaababbaaababbaabbabbabbabababbabababbbabbbbbabababbaabababbabaabaaabaababbaabaababababbaabbbabbbbbababababbababaab
    1 length: 150
    2 length: 150
    

    Java version: 1.6.0_45 and I am using eclipse version: Eclipse Java EE IDE for Web Developers. Version: Juno Service Release 2 Build id: 20130225-0426

    UPDATE 1: I ran this outside eclipse and now they seem to be matching, but I am getting ArrayIndexOutOfBoundsException sometimes:

    $ java -version
    java version "1.6.0_27"
    OpenJDK Runtime Environment (IcedTea6 1.12.5) (6b27-1.12.5-0ubuntu0.12.04.1)
    OpenJDK Server VM (build 20.0-b12, mixed mode)
    
    $ java ThreadTester
    1: ababbbbbabbabababababaababbaabbbaabababbbababbabababbabbababbbbbbabaabaababbbbbbabbbbbaabbaaabbbbaabbbababababbbbabbababab
    1 length: 123
    2: ababbbbbabbabababababaababbaabbbaabababbbababbabababbabbababbbbbbabaabaababbbbbbabbbbbaabbaaabbbbaabbbababababbbbabbababab
    2 length: 123
    
    $ java ThreadTester 
    2: abbabaabbbbbbbbbababbbbbabbbabbbabaaabbbbbbbabababbbbbbbbbabbbbbbbababababbabbbbaabbbaaabbabaaababaaaabaabbaabbbb
    2 length: 115
    1: abbabaabbbbbbbbbababbbbbabbbabbbabaaabbbbbbbabababbbbbbbbbabbbbbbbababababbabbbbaabbbaaabbabaaababaaaabaabbaabbbb
    1 length: 115
    
    $ java ThreadTester 
    Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException
        at java.lang.System.arraycopy(Native Method)
        at java.lang.String.getChars(String.java:862)
        at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:408)
        at java.lang.StringBuilder.append(StringBuilder.java:136)
        at StringContainer.addToSb(StringContainer.java:14)
        at ThreadTester.main(ThreadTester.java:14)
    2: abbbbbbababbbbabbbbababbbbaabbabbbaaabbbababbbbabaabaabaabaaabababaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
    2 length: 114
    

    The ArrayIndexOutOfBoundsException is also happening when running from eclipse.

    UPDATE 2: There are two problems happening. The first problem of the contents of the StringBuilder not matching the length is happening only in Eclipse and not when I run in command line (at least the 100+ times I ran it on command line it never happened).

    The second problem with ArrayIndexOutOfBoundsException should be to do with the internal implementation of StringBuilder class, which keeps an array of chars and does an Arrays.copyOf when it expands the size. But it still beats me how a write is happening before the size is expanded, no matter what the order of execution is.

    BTW, I am inclined to agree with @GreyBeardedGeek's answer that this whole exercise is a huge waste of time :-). Sometimes we get to see only the symptoms i.e. the output of some code and wonder what is going wrong. This question declared a priori that two threads are modifying a (very well-known) thread unsafe object.

    UPDATE 3: Here is the official answer from Java Concurrency in Practice p. 35:

    • In the absence of synchronization, the compiler, processor and runtime can do some downright weird things to the order in which operations appear to execute. Attempts to reason about the order in which memory actions "must" happen in insufficiently synchronized multithreaded programs will almost certainly be incorrect.

    • Reasoning about insufficiently synchronized concurrent programs is prohibitively difficult.

    There is also a nice example NoVisibility in the book on p. 34.

    The behavior of a non-threadsafe class when accessed concurrently by multiple threads is by definition "undefined".

    Any attempt to ascertain deterministic behavior in such a case is, IMHO, just a huge waste of time.

    In Java Concurrency in Practice one of the examples that I think surprises people (at least me) is something like this:

    public class Foo {
    
      private int n;
    
      public Foo(int n) {
        this.n = n;
      }
    
      public void check() {
        if (n != n) throw new AssertionError("huh?");
    
      }
    }
    

    The surprise (to me at least) was the claim that this is not thread safe, and not only it's not safe, but also there is a chance that the check method will throw the assertion error.

    The explanation is that without synchronization / marking n as volatile, there is no visibility guarantee between different threads, and that the value of n can change while a thread is reading it.

    But I wonder how likely it is to happen in practice. Or better, if I could replicate it somehow.

    So I was trying to write code that will trigger that assertion error, without luck.

    Is there a straight forward way to write a test that will prove that this visibility issue is not just theoretical?

    Or is it something that changed in the more recent JVMs?

    EDIT: related question: Not thread safe Object publishing

    But I wonder how likely it is to happen in practice.

    Highly unlikely esp as the JIT can turn n into a local variable and only read it one.

    The problem with highly unlikely thread safety bugs is that one day, you might change something which shouldn't matter, like your choice of processor or JVM and suddenly your code breaks randomly.

    Or better, if I could replicate it somehow.

    There is not guarantee you can reproduce it either.

    Is there a straight forward way to write a test that will prove that this visibility issue is not just theoretical?

    In some cases, yes. but this one is a hard one to prove, partly because the JVM is not prevented from being more thread safe than the JLS says is the minimum.

    For example, the HotSpot JVM often does what you might expect, not just the minimum in the docuemtation. e.g. System.gc() is only a hint according to the javadoc, but by default the HotSpot JVM will do it every time.

    The ultimate goal is to add extra behavior to ListenableFutures based on the type of the Callable/Runnable argument. I want to add extra behavior to each of the Future methods. (Example use cases can be found in AbstractExecutorService's javadoc and section 7.1.7 of Goetz's Java Concurrency in Practice)

    I have an existing ExecutorService which overrides newTaskFor. It tests the argument's type and creates a subclass of FutureTask. This naturally supports submit as well as invokeAny and invokeAll.

    How do I get the same effect for the ListenableFutures returned by a ListeningExecutorService?

    Put another way, where can I put this code

    if (callable instanceof SomeClass) {
       return new FutureTask<T>(callable) {
            public boolean cancel(boolean mayInterruptIfRunning) {
                System.out.println("Canceling Task");
                return super.cancel(mayInterruptIfRunning);
            }
        };
    } else {
        return new FutureTask<T>(callable);
    }
    

    such that my client can execute the println statement with

    ListeningExecutorService executor = ...;
    Collection<Callable> callables = ImmutableSet.of(new SomeClass());
    List<Future<?>> futures = executor.invokeAll(callables);
    for (Future<?> future : futures) {
        future.cancel(true);
    }
    

    Failed Solutions

    Here's a list of things I've already tried and why they don't work.

    Solution A

    Pass MyExecutorService to MoreExecutors.listeningDecorator.

    Problem 1: Unfortunately the resulting ListeningExecutorService (an AbstractListeningExecutorService) doesn't delegate to the ExecutorService methods, it delegates to the execute(Runnable) method on Executor. As a result, the newTaskFor method on MyExecutorService is never called.

    Problem 2: AbstractListeningExecutorService creates the Runnable (a ListenableFutureTask) via static factory method which I can't extend.

    Solution B

    Inside newTaskFor, create MyRunnableFuture normally and then wrap it with a ListenableFutureTask.

    Problem 1: ListenableFutureTask's factory methods don't accept RunnableFutures, they accept Runnable and Callable. If I pass MyRunnableFuture as a Runnable, the resulting ListenableFutureTask just calls run() and not any of the Future methods (where my behavior is).

    Problem 2: Even if it did call my Future methods, MyRunnableFuture is not a Callable, so I have to supply a return value when I create the ListenableFutureTask... which I don't have... hence the Callable.

    Solution C

    Let MyRunnableFuture extend ListenableFutureTask instead of FutureTask

    Problem: ListenableFutureTask is now final (as of r10 / r11).

    Solution D

    Let MyRunnableFuture extend ForwardingListenableFuture and implement RunnableFuture. Then wrap the SomeClass argument in a ListenableFutureTask and return that from delegate()

    Problem: It hangs. I don't understand the problem well enough to explain it, but this configuration causes a deadlock in FutureTask.Sync .

    Source Code: As requested, here's the source for Solution D which hangs:

    import java.util.*;
    import java.util.concurrent.*;
    import com.google.common.collect.ImmutableSet;
    import com.google.common.util.concurrent.*;
    
    /** See http://stackoverflow.com/q/8931215/290943 */
    public final class MyListeningExecutorServiceD extends ThreadPoolExecutor implements ListeningExecutorService {
    
        // ===== Test Harness =====
    
        private static interface SomeInterface {
            public String getName();
        }
    
        private static class SomeClass implements SomeInterface, Callable<Void>, Runnable {
            private final String name;
    
            private SomeClass(String name) {
                this.name = name;
            }
    
            public Void call() throws Exception {
                System.out.println("SomeClass.call");
                return null;
            }
    
            public void run() {
                System.out.println("SomeClass.run");
            }
    
            public String getName() {
                return name;
            }
        }
    
        private static class MyListener implements FutureCallback<Void> {
            public void onSuccess(Void result) {
                System.out.println("MyListener.onSuccess");
            }
    
            public void onFailure(Throwable t) {
                System.out.println("MyListener.onFailure");
            }
        }
    
        public static void main(String[] args) throws InterruptedException {
            System.out.println("Main.start");
    
            SomeClass someClass = new SomeClass("Main.someClass");
    
            ListeningExecutorService executor = new MyListeningExecutorServiceD();
            Collection<Callable<Void>> callables = ImmutableSet.<Callable<Void>>of(someClass);
            List<Future<Void>> futures = executor.invokeAll(callables);
    
            for (Future<Void> future : futures) {
                Futures.addCallback((ListenableFuture<Void>) future, new MyListener());
                future.cancel(true);
            }
    
            System.out.println("Main.done");
        }
    
        // ===== Implementation =====
    
        private static class MyRunnableFutureD<T> extends ForwardingListenableFuture<T> implements RunnableFuture<T> {
    
            private final ListenableFuture<T> delegate;
            private final SomeInterface someClass;
    
            private MyRunnableFutureD(SomeInterface someClass, Runnable runnable, T value) {
                assert someClass == runnable;
                this.delegate = ListenableFutureTask.create(runnable, value);
                this.someClass = someClass;
            }
    
            private MyRunnableFutureD(SomeClass someClass, Callable<T> callable) {
                assert someClass == callable;
                this.delegate = ListenableFutureTask.create(callable);
                this.someClass = someClass;
            }
    
            @Override
            protected ListenableFuture<T> delegate() {
                return delegate;
            }
    
            public void run() {
                System.out.println("MyRunnableFuture.run");
                try {
                    delegate.get();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                } catch (ExecutionException e) {
                    e.printStackTrace();
                }
            }
    
            @Override
            public boolean cancel(boolean mayInterruptIfRunning) {
                System.out.println("MyRunnableFuture.cancel " + someClass.getName());
                return super.cancel(mayInterruptIfRunning);
            }
        }
    
        public MyListeningExecutorServiceD() {
            // Same as Executors.newSingleThreadExecutor for now
            super(1, 1, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>());
        }
    
        @Override
        protected <T> RunnableFuture<T> newTaskFor(Runnable runnable, T value) {
            if (runnable instanceof SomeClass) {
                return new MyRunnableFutureD<T>((SomeClass) runnable, runnable, value);
            } else {
                return new FutureTask<T>(runnable, value);
            }
        }
    
        @Override
        protected <T> RunnableFuture<T> newTaskFor(Callable<T> callable) {
            if (callable instanceof SomeClass) {
                return new MyRunnableFutureD<T>((SomeClass) callable, callable);
            } else {
                return new FutureTask<T>(callable);
            }
        }
    
        /** Must override to supply co-variant return type */
        @Override
        public ListenableFuture<?> submit(Runnable task) {
            return (ListenableFuture<?>) super.submit(task);
        }
    
        /** Must override to supply co-variant return type */
        @Override
        public <T> ListenableFuture<T> submit(Runnable task, T result) {
            return (ListenableFuture<T>) super.submit(task, result);
        }
    
        /** Must override to supply co-variant return type */
        @Override
        public <T> ListenableFuture<T> submit(Callable<T> task) {
            return (ListenableFuture<T>) super.submit(task);
        }
    }
    

    Based on this question and a couple others discussions I've had recently, I'm coming to the conclusion that RunnableFuture/FutureTask is inherently misleading: Clearly you submit a Runnable, and clearly you get a Future back, and clearly the underlying Thread needs a Runnable. But why should a class implement both Runnable and Future? And if it does, which Runnable is it replacing? That's bad enough already, but then we introduce multiple levels of executors, and things really get out of hand.

    If there's a solution here, I think it's going to require treating FutureTask as an implementation detail of AbstractExecutorService. I'd focus instead on splitting the problem into two pieces:

    • I want to conditionally modify the returned Future.
    • I want to conditionally modify the code run by the executor service. (I'm actually not sure whether this is a requirement here, but I'll cover it in case it is. Even if not, it may help establish the Runnable/Future distinction.)

    (grumble Markdown grumble)

    class MyWrapperExecutor extends ForwardingListeningExecutorService {
      private final ExecutorService delegateExecutor;
    
      @Override public <T> ListenableFuture<T> submit(Callable<T> task) {
        if (callable instanceof SomeClass) {
          // Modify and submit Callable (or just submit the original Callable):
          ListenableFuture<T> delegateFuture =
              delegateExecutor.submit(new MyCallable(callable));
          // Modify Future:
          return new MyWrapperFuture<T>(delegateFuture);
        } else {
          return delegateExecutor.submit(callable);
        }
      }
    
      // etc.
    }
    

    Could that work?

    Can anybody explain how thread priority works in java. The confusion here is if java does'nt guarantee the implementation of the Thread according to its priority then why is this setpriority() function used for.

    My code is as follows :

    public class ThreadSynchronization implements Runnable{
    
        public synchronized void run() {
            System.out.println("Starting Implementation of Thread "+Thread.currentThread().getName());
            for(int i=0;i<10;i++)
            {
                System.out.println("Thread "+Thread.currentThread().getName()+" value : "+i);
            }
            System.out.println("Ending Implementation of Thread "+Thread.currentThread().getName());
        }
    
        public static void main(String[] args) {
            System.out.println("Program starts...");
            ThreadSynchronization th1 = new ThreadSynchronization();
            Thread t1 = new Thread(th1);
            t1.setPriority(1);
            synchronized(t1)
            {
                t1.start();
            }
    
            ThreadSynchronization th2 = new ThreadSynchronization();
            Thread t2 = new Thread(th2);
            t2.setPriority(9);
            synchronized (t2) {
                t2.start(); 
            }
    
            System.out.println("Program ends...");
        }
    }
    

    In the above program even if I change the priority I find no difference in the output. Also a real time application of how thread priority can be used would be of great help. Thanks.

    Thread priority is just a hint to OS task scheduler and is dependent on the underlying OS. OS will try to allocate more resources to a high priority thread but it does not guarantee it. So if your program is dependent on thread priorities than you are in-turn binding your program to underlying OS, which is bad.

    From Java Concurrency in Practice:

    Avoid the temptation to use thread priorities, since they increase platform dependence and can cause liveness problems. Most concurrent applications can use the default priority for all threads.

    Hi,

    I'm using Scala 2.10 with the new futures library and I'm trying to write some code to test an infinite loop. I use a scala.concurrent.Future to run the code with the loop in a separate thread. I would then like to wait a little while to do some testing and then kill off the separate thread/future. I have looked at Await.result but that doesn't actually kill the future. Is there any way to timeout or kill the new Scala 2.10 futures?

    I would prefer not having to add external dependencies such as Akka just for this simple part.

    No - you will have to add a flag that your loop checks. If the flag is set, stop the loop. Make sure the flag is at least volatile.

    See Java Concurrency in Practice, p 135-137.

    I am aware that the purpose of volatile variables in Java is that writes to such variables are immediately visible to other threads. I am also aware that one of the effects of a synchronized block is to flush thread-local memory to global memory.

    I have never fully understood the references to 'thread-local' memory in this context. I understand that data which only exists on the stack is thread-local, but when talking about objects on the heap my understanding becomes hazy.

    I was hoping that to get comments on the following points:

    1. When executing on a machine with multiple processors, does flushing thread-local memory simply refer to the flushing of the CPU cache into RAM?

    2. When executing on a uniprocessor machine, does this mean anything at all?

    3. If it is possible for the heap to have the same variable at two different memory locations (each accessed by a different thread), under what circumstances would this arise? What implications does this have to garbage collection? How aggressively do VMs do this kind of thing?

    4. (EDIT: adding question 4) What data is flushed when exiting a synchronized block? Is it everything that the thread has locally? Is it only writes that were made inside the synchronized block?

      Object x = goGetXFromHeap(); // x.f is 1 here    
      Object y = goGetYFromHeap(); // y.f is 11 here
      Object z = goGetZFromHead(); // z.f is 111 here
      
      y.f = 12;
      
      synchronized(x)
      {
          x.f = 2;
          z.f = 112;
      }
      
      // will only x be flushed on exit of the block? 
      // will the update to y get flushed?
      // will the update to z get flushed?
      

    Overall, I think am trying to understand whether thread-local means memory that is physically accessible by only one CPU or if there is logical thread-local heap partitioning done by the VM?

    Any links to presentations or documentation would be immensely helpful. I have spent time researching this, and although I have found lots of nice literature, I haven't been able to satisfy my curiosity regarding the different situations & definitions of thread-local memory.

    Thanks very much.

    It is really an implementation detail if the current content of the memory of an object that is not synchronized is visible to another thread.

    Certainly, there are limits, in that all memory is not kept in duplicate, and not all instructions are reordered, but the point is that the underlying JVM has the option if it finds it to be a more optimized way to do that.

    The thing is that the heap is really "properly" stored in main memory, but accessing main memory is slow compared to access the CPU's cache or keeping the value in a register inside the CPU. By requiring that the value be written out to memory (which is what synchronization does, at least when the lock is released) it forcing the write to main memory. If the JVM is free to ignore that, it can gain performance.

    In terms of what will happen on a one CPU system, multiple threads could still keep values in a cache or register, even while executing another thread. There is no guarantee that there is any scenario where a value is visible to another thread without synchronization, although it is obviously more likely. Outside of mobile devices, of course, the single-CPU is going the way of floppy disks, so this is not going to be a very relevant consideration for long.

    For more reading, I recommend Java Concurrency in Practice. It is really a great practical book on the subject.

    I know that finally blocks in deamon threads would not be executed. But my meticulous nature tries to understand why and what happens in JVM so special that it could not call the code under this block.

    I think that it somehow related to call stack that it whould not unwind, but don't know how. Can someone please shed some light on this. Thanks.

    If the JVM exits while the try or catch code is being executed, then the finally block may not execute.
    Normal Shutdown - this occurs either when the last non-daemon thread exits OR when Runtime.exit()
    When a thread exits, the JVM performs an inventory of running threads, and if the only threads that are left are daemon threads, it initiates an orderly shutdown. When the JVM halts, any remaining daemon threads are abandoned finally blocks are not executed, stacks are not unwound the JVM just exits. Daemon threads should be used sparingly few processing activities can be safely abandoned at any time with no cleanup. In particular, it is dangerous to use daemon threads for tasks that might perform any sort of I/O. Daemon threads are best saved for "housekeeping" tasks, such as a background thread that periodically removes expired entries from an in-memory cache.

    Last non-daemon thread exits example:

    public class TestDaemon {
        private static Runnable runnable = new Runnable() {
            @Override
            public void run() {
                try {
                    while (true) {
                        System.out.println("Is alive");
                        Thread.sleep(10);
                        // throw new RuntimeException();
                    }
                } catch (Throwable t) {
                    t.printStackTrace();
                } finally {
                    System.out.println("This will never be executed.");
                }
            }
        };
    
        public static void main(String[] args) throws InterruptedException {
            Thread daemon = new Thread(runnable);
            daemon.setDaemon(true);
            daemon.start();
            Thread.sleep(100);
            // daemon.stop();
            System.out.println("Last non-daemon thread exits.");
        }
    }
    

    Output:

    Is alive
    Is alive
    Is alive
    Is alive
    Is alive
    Is alive
    Is alive
    Is alive
    Is alive
    Is alive
    Last non-daemon thread exits.
    Is alive
    Is alive
    Is alive
    Is alive
    Is alive
    

    I've got a highly multithreaded app written in Ruby that shares a few instance variables. Writes to these variables are rare (1%) while reads are very common (99%). What is the best way (either in your opinion or in the idiomatic Ruby fashion) to ensure that these threads always see the most up-to-date values involved? Here's some ideas so far that I had (although I'd like your input before I overhaul this):

    • Have a lock that most be used before reading or writing any of these variables (from Java Concurrency in Practice). The downside of this is that it puts a lot of synchronize blocks in my code and I don't see an easy way to avoid it.
    • Use Ruby's freeze method (see here), although it looks equally cumbersome and doesn't give me any of the synchronization benefits that the first option gives.

    These options both seem pretty similar but hopefully anyone out there will have a better idea (or can argue well for one of these ideas). I'd also be fine with making the objects immutable so they aren't corrupted or altered in the middle of an operation, but I don't know Ruby well enough to make the call on my own and this question seems to argue that objects are highly mutable.

    Using the lock is the most appropiate way to do this. You can see this presentation by Jim Weirich on the subject: What All Rubyist Should Know About Threading.

    Also, freezing an object won't help you here since you want to modify these variables. Freezing them in place means that no further modifications will be applicable to these (and therefore your 1% of writes won't work).

    This question relates to Java collections - specifically Hashtable and Vector - but may also apply elsewhere.

    I've read in many places how good it is to program to interfaces and I agree 100%. The ability to program to a List interface, for instance, without regard for the underlying implementation is most certainly helpful for decoupling and testing purposes. With collections, I can see how an ArrayList and a LinkedList are applicable under different circumestances, given the differences with respect to internal storage structure, random access times, etc. Yet, these two implementations can be used under the same interface...which is great.

    What I can't seem to place is how certain synchronized implementations (in particular Hashtable and Vector) fit in with these interfaces. To me, they don't seem to fit the model. Most of the underlying data structure implementations seem to vary in how the data is stored (LinkedList, Array, sorted tree, etc.), whereas synchronization deals with conditions (locking conditions) under which the data may be accessed. Let's look at an example where a method returns a Map collection:

    public Map<String, String> getSomeData();
    

    Let's assume that the application is not concerned at all with concurrency. In this case, we operate on whatever implementation the method returns via the interface...Everybody is happy. The world is stable.

    However, what if the application now requires attention on the concurrency front? We now cannot operate without regard for the underlying implementation - Hashtable would be fine, but other implementations must be catered for. Let's consider 3 scenarios:

    1) Enforce synchronization using synchronization blocks, etc. when adding/removing with the collection. Wouldn't this, however, be overkill in the event that a synchronized implementation (Hashtable) gets returned?

    2) Change the method signature to return Hashtable. This, however, tightly binds us to the Hashtable implementation, and as a result, the advantages of programming to an interface are thrown out the window.

    3) Make use of the concurrent package and change the method signature to return an implementation of the ConcurrentMap interface. To me, this seems like the way forward.

    Essentially, it just seems like certain synchronized implementations are a bit of a misfit within the collections framework in that, when programming to interfaces, the synchronization issue almost forces one to think about the underlying implementation.

    Am I completely missing the point here?

    Thanks.

    What you are struggling with is the fact that in a multi-threaded environment, a client cannot naively use an object that has mutable, shared state. The collection interface, by itself, tells you nothing about how the object can be used safely. Returning a ConcurrentMap helps give some additional information but only for that particular case.

    Normally, you have to communicate the thread safety issues separately in documentation (e.g., javadoc) or by using custom annotations as is described in Java Concurrency in Practice. The client of the returned object will have to use its own locking mechanism or one that you provide. The interface is usually orthogonal to the thread safety.

    It's not a problem if the client knows that all the implementations are from the Concurrent implementations, but that information is not communicated by the interface itself.

    From Java Concurrency in practice Chapter 3.3.3. ThreadLocal

    Thread-local variables are often used to prevent sharing in designs based on mutable Singletons or global variables.

    If we wrap the mutable Singleton guy in a ThreadLocal each thread will have its own copy of the Singleton ? How will it remain a singleton then ? Is this what the authors meant or am I missing something pretty obvious here ?

    If we wrap the mutable Singleton guy in a ThreadLocal

    AFAIK you do not wrap the singleton class with ThreadLocal, but the object contained within the singleton which is mutable or non-thread safe. As the example discusses correctly that the JDBC Connection is not thread safe and will require additional protection, which in turn increases contention.

    So in the cases when the Singletons are used just for the purpose of sharing, then replacing those things with ThreadLocal is a good idea, as all the threads have their own Connection and no more added protection is required.

    Other good example of use case of ThreadLocal is Random generation, if there is a single Random object then there is contention within threads for the "seed", so if each thread has its own Random object then there is no contention any more and that makes sense.

    I heard many times that Java Swing threading model is wrong. I don't fully understand why, I know that the problem is related to the fact that you can draw on a Drawable from another thread other than the main UI thread. I know that there are utility functionalities like SwingUtilities.invokeAndWait and SwingUtilities.invokeLater that let you do your painting in a Runnable, that in turn is run by the Event Dispatcher thread. I guess that this way you ensure that painting is done synchronously and this doesn't leave the buffer in an incosistent state.

    My question is: how do "good" UI toolkits behave? What solutions are adopted?

    Brian Goetz's Java Concurrency in Practice,

    9.1 Why are GUIs single-threaded?:

    ...In the old days, GUI applications were single-threaded and GUI events were processed from a “main event loop”. Modern GUI frameworks use a model that is only slightly different: they create a dedicated event dispatch thread (EDT) for handling GUI events. Single-threaded GUI frameworks are not unique to Java; Qt, NextStep, MacOS Cocoa, X Windows, and many others are also single-threaded. This is not for lack of trying; there have been many attempts to write multithreaded GUI frameworks, but because of persistent problems with race conditions and deadlock, they all eventually arrived at the single-threaded event queue model in which a dedicated thread fetches events off a queue and dispatches them to application-defined event handlers...

    I'm currently reviewing/refactoring a multithreaded application which is supposed to be multithreaded in order to be able to use all the available cores and theoretically deliver a better / superior performance (superior is the commercial term for better :P)

    What are the things I should be aware when programming multithreaded applications?

    I mean things that will greatly impact performance, maybe even to the point where you don't gain anything with multithreading at all but lose a lot by design complexity. What are the big red flags for multithreading applications?

    Should I start questioning the locks and looking to a lock-free strategy or are there other points more important that should light a warning light?

    Edit: The kind of answers I'd like are similar to the answer by Janusz, I want red warnings to look up in code, I know the application doesn't perform as well as it should, I need to know where to start looking, what should worry me and where should I put my efforts. I know it's kind of a general question but I can't post the entire program and if I could choose one section of code then I wouldn't be needing to ask in the first place.

    I'm using Delphi 7, although the application will be ported / remake in .NET (c#) for the next year so I'd rather hear comments that are applicable as a general practice, and if they must be specific to either one of those languages

    You should first be familiar with Amdahl's law.

    If you are using Java, I recommend the book Java Concurrency in Practice; however, most of its help is specific to the Java language (Java 5 or later).

    In general, reducing the amount of shared memory increases the amount of parallelism possible, and for performance that should be a major consideration.

    Threading with GUI's is another thing to be aware of, but it looks like it is not relevant for this particular problem.

    I need to run some code for a predefined length of time, when the time is up it needs to stop. Currently I am using a TimerTask to allow the code to execute for a set amount of time but this is causing endless threads to be created by the code and is just simply not efficient. Is there a better alternative?

    Current code;

    // Calculate the new lines to draw 
                Timer timer3 = new Timer();
                timer3.schedule(new TimerTask(){
                    public void run(){
                        ArrayList<String> Coords = new ArrayList<String>();
                        int x = Float.valueOf(lastFour[0]).intValue();
                        int y = Float.valueOf(lastFour[1]).intValue();
                        int x1 = Float.valueOf(lastFour[2]).intValue();
                        int y1 = Float.valueOf(lastFour[3]).intValue();
                        //Could be the wrong way round (x1,y1,x,y)?
                        Coords = CoordFiller.coordFillCalc(x, y, x1, y1);
                        String newCoOrds = "";
                        for (int j = 0; j < Coords.size(); j++)
                        {
                            newCoOrds += Coords.get(j) + " ";
                        }
                        newCoOrds.trim();
                        ClientStorage.storeAmmendedMotion(newCoOrds);
    
                    }
    
                }
                ,time);
    

    If you are using Java5 or later, consider ScheduledThreadPoolExecutor and Future. With the former, you can schedule tasks to be run after a specified delay, or at specified intervals, thus it takes over the role of Timer, just more reliably.

    The Timer facility manages the execution of deferred ("run this task in 100 ms") and periodic ("run this task every 10 ms") tasks. However, Timer has some drawbacks, and ScheduledThreadPoolExecutor should be thought of as its replacement. [...]

    A Timer creates only a single thread for executing timer tasks. If a timer task takes too long to run, the timing accuracy of other TimerTasks can suffer. If a recurring TimerTask is scheduled to run every 10 ms and another TimerTask takes 40 ms to run, the recurring task either (depending on whether it was scheduled at fixed rate or fixed delay) gets called four times in rapid succession after the long-running task completes, or "misses" four invocations completely. Scheduled thread pools address this limitation by letting you provide multiple threads for executing deferred and periodic tasks.

    Another problem with Timer is that it behaves poorly if a TimerTask throws an unchecked exception. The Timer thread doesn't catch the exception, so an unchecked exception thrown from a TimerTask terminates the timer thread. Timer also doesn't resurrect the thread in this situation; instead, it erroneously assumes the entire Timer was cancelled. In this case, TimerTasks that are already scheduled but not yet executed are never run, and new tasks cannot be scheduled.

    From Java Concurrency in Practice, section 6.2.5.

    And Futures can be constrained to run at most for the specified time (throwing a TimeoutException if it could not finish in time).

    Update

    If you don't like the above, you can make the task measure its own execution time, as below:

    int totalTime = 50000; // in nanoseconds
    long startTime = System.getNanoTime();
    boolean toFinish = false;
    
    while (!toFinish) 
    {
        System.out.println("Task!");
        ...
        toFinish = (System.getNanoTime() - startTime >= totalTime);
    }
    

    In Java concurrency, what makes a thread "active"? Just the fact that it's not idling? Is a "waiting" or "suspended" thread still considered, technically, active?

    In this context I take "active" to mean that they are executing code. Inactive threads--those that are blocked on I/O calls or awaiting locks--consume only memory resources without affecting the CPU (or only marginally).

    However, it really depends on what your threads are doing. If each thread is iterating over numbers to calculate primes, they are fully CPU-bound, and you should really only have one per core to maximize throughput. If they are making HTTP requests or performing file I/O, you can afford to have quite a few per core.

    In the end, a blanket statement covering all threads in general without regard for what they are doing is pretty worthless.

    I highly recommend the book Java Concurrency in Practice for a high-quality treatment of the topic of concurrent Java programming.

    Will Thread priority increases accuracy of Thread.sleep(50);?

    As we know Threads aren't accurate when you call sleep for 50ms, But does it increases accuracy by any mean? If thread is listed as MAX_PRIORITY.

    Will be thankful for any kind of explanation.

    Yes it may make it more accurate.

    Nevertheless, from Java Concurrency In Practice, by Brian goetz:

    The thread priority mechanism is a blunt instrument, and it's not always obvious what effect changing priorities will have; boosting a thread's priority might do nothing or might always cause one thread to be scheduled in preference to the other, causing starvation.

    It is generally wise to resist the temptation to tweak thread priorities. As soon as you start modifying priorities, the behavior of your application becomes platform-specific and you introduce the risk of starvation. You can often spot a program that is trying to recover from priority tweaking or other responsiveness problems by the presence of Thread.sleep or Thread.yield calls in odd places, in an attempt to give more time to lower-priority threads.

    Therefore avoid changing the thread priorities and re-think your design if you really need your Thread.sleep(50) to be that accurate!

    When using threads I sometimes visualise them as weaving together 3 or more dimensional interconnections between Objects in a Spatial context. This isn't a general use case scenario, but for what I do it is a useful way to think about it.

    Are there any APIs which you use which aid threading?

    Have you used threads in a manner which doesn't conceptualise as thread being a process?

    Concurrency is a deep and complicated topic to cover. Books like Java Concurrency in Practice may help.

    See Concurrency Utilities Overview for APIs on threading. BlockingQueue<E> can be useful for example.

    A Queue that additionally supports operations that wait for the queue to become non-empty when retrieving an element, and wait for space to become available in the queue when storing an element.

    See CountDownLatch

    A synchronization aid that allows one or more threads to wait until a set of operations being performed in other threads completes.

    and CyclicBarrier for some interesting behavior.

    A synchronization aid that allows a set of threads to all wait for each other to reach a common barrier point.

    Edit: I am reading Java Concurrency in Practice now. It's very good.

    From the famous book Java Concurrency in Practice chapter 3.4.1 Final fields

    Just as it is a good practice to make all fields private unless they need greater visibility[EJ Item 12] , it is a good practice to make all fields final unless they need to be mutable.

    My understanding of final references in Java : A final reference/ field just prevents the the field from getting re initialized but if it references a mutable object , we can still change its state rendering it mutable . So I am having difficulty understanding the above quote . What do you think ?

    final fields prevent you from changing the field itself (by making it "point" to some other instance), but if the field is a reference to a mutable object, nothing will stop you from doing this:

    public void someFunction (final Person p) {
        p = new Person("mickey","mouse"); //cant do this - its final
        p.setFirstName("donald");
        p.setLastName("duck");
    }
    

    the reference p above is immutable, but the actual Person pointed to by the reference is mutable. you can, of course, make class Person an immutable class, like so:

    public class Person {
        private final String firstName;
        private final String lastName;
        public Person(String firstName, String lastName) {
            this.firstName = firstName;
            this.lastName = lastName;
        }
        //getters and other methods here
    }
    

    such classes once created, cannot be modified in any way.

    I am not understanding this concept in any manner.

    public class SomeName {
    
         public static void main(String args[]) {
    
         }
    
    }
    

    This is my class SomeName. Now what is thread here.

    1. Do we call the class as a thread.
    2. Do we call this class as thread when some other object is trying to access its method or members?
    3. Do we call this class as thread when some other object is trying to access this object?
    4. What does it mean when we call something in java as thread-safe ?

    You might want to think of thread as CPU executing the code that you wrote.

    What is thread?

    A thread is a single sequential flow of control within a program.

    From Java concurrency in practice:

    Thread-safe classes encapsulate any needed synchronization so that clients need not provide their own.

    I'd like to kill threads that are stuck in deadlock state. First, we can detect thread ids in deadlock state using the findDeadlockedThreads() method of the ThreadMXBean class in java.lang.management.

    Then, I'd like to kill the threads by thread ids, and thus I have two related questions:
    (1) How to get the control of a thread by thread id?
    (2) How to kill a blocked thread? I think that invokting interrupt() method will give an exception to the thread and will kill the thread.

    Let's say I have the following,

    public class Foo{
        private String bar;
    
        public String getBar(){
            return bar;
        }
    
        public void setBar(String bar){
            this.bar = bar;
        }
    }
    

    Are these methods automatically threadsafe due to the immutable nature of the String class, or is some locking mechanism required?

    No, this is not threadsafe. Foo is mutable, so if you want to ensure that different threads see the same value of bar – that is, consistency – either:

    • Make bar volatile, or
    • Make the methods synchronized, or
    • Use an AtomicReference<String>.

    The reads and writes of bar are themselves atomic, but atomicity is not thread safety.

    http://docs.oracle.com/javase/tutorial/essential/concurrency/atomic.html


    For in-depth coverage of Java concurrency, grab a copy of Java Concurrency in Practice (aka JCIP).

    Q1. What is a condVar in Java? If I see the code below, does a condition variable necessarily have to be within the 'mutex.acquire()' and 'mutex.release()' block?

    public void put(Object x) throws InterruptedException {
       mutex.acquire();
       try {
          while (count == array.length)
          notFull.await();
          array[putPtr] = x;
          putPtr = (putPtr + 1) % array.length;
          ++count;
          notEmpty.signal();
      }
      finally {
         mutex.release();
      }
    }
    

    I have three threads myThreadA, myThreadB, myThreadC running which call the same function commonActivity() which triggers the function myWorkReport() e.g.

    public void myWorkReport(){
        mutexMyWork.acquire();
        try{
             while(runMyWork){
                 doWork();
                 conditionMyWork.timedwait(sleepMyWork);
             }
        }
        finally{
           mutexMyWork.release()
        }    
    }
    
    public void commonActivity(){
        try{
            conditionMyWork.signal(); 
        }finally{
            //cleanup
        }   
    }
    
    public void myThreadA(){
        mutexA.acquire();
        try{
            while(runningA){    //runningA is a boolean variable, this is always true as long as application is running
                conditionA.timedwait(sleepA);
                commonActivity();
            }
        }
        finally{
            mutexA.release();
        }
    }
    
    
    public void myThreadB(){
        mutexB.acquire();
        try{
            while(runningB){    //runningB is a boolean variable, this is always true as long as application is running
                conditionB.timedwait(sleepB);
                commonActivity();
            }
        }
        finally{
            mutexB.release();
        }
    }
    
    public void myThreadC(){
        mutexC.acquire();
        try{
            while(runningC){    //runningC is a boolean variable, this is always true as long as application is running.
                conditionC.timedwait(sleepC);
                commonActivity();
            }
        }
        finally{
            mutexC.release();
        }
    }
    

    Q2. Is using timedwait a good practice. I could have achieved the same by using sleep(). If using sleep() call is bad, Why?

    Q3. Is there any better way to do the above stuff?

    Q4. Is it mandatory to have condition.signal() for every condition.timedwait(time);

    Q1: A Condition object is associated (and acquired from) a Lock (aka mutext) object. The javadoc for the class is fairly clear as to its usage and application. To wait on the condition you need to have acquired the lock, and it is good coding practice to do so in a try/finally block (as you have). As soon as the thread that has acquired the lock waits on a condition for that lock, the lock is relinquished (atomically).

    Q2: Using timed wait is necessary to insure liveness of your program in case where the condition you are waiting for never occurs. Its definitely a more sophisticated form, and it is entirely useless if you do not check for the fact that you have timed out and take action to handle the time out condition.

    Using sleep is an acceptable form of waiting for something to occur, but if you are already using a Lock ("mutex") and have a condition variable for that lock, it make NO sense not to use the time wait method of the condition:

    For example, in your code, you are simply waiting for a given period but you do NOT check to see if condition occurred or if you timed out. (That's a bug.) What you should be doing is checking to see if your timed call returned true or false. (If it returns false, then it timed out & the condition has NOT occured (yet)).

    public void myThreadA(){
        mutexA.acquire();
        try{
            while(runningA){    //runningA is a boolean variable
                if(conditionA.await (sleepATimeoutNanos))
                    commonActivity();
                else {
                    // timeout!  anything sensible to do in that case? Put it here ...
                }
            }
        }
        finally{
            mutexA.release();
        }
    }
    

    Q3: [edited] The code fragments require a more detailed context to be comprehensible. For example, its not entirely clear if the conditions in the threads are all the same (but am assuming that they are).

    If all you are trying to do is insure commonActivity() is executed only by one thread at a time, AND, certain sections of the commonActivity() do NOT require contention control, AND, you do require the facility to time out on your waits, then, you can simply use a Semaphore. Note that sempahore has its own set of methods for timed waits.

    If ALL of the commonActivity() is critical, AND, you really don't mind waiting (without timeouts) simply make commonActivity() a synchronized method.

    [final edit:)] To be more formal about it, conditions are typically used in scenarios where you have two or more thread co-operating on a task and you require hand offs between the threads.

    For example, you have a server that is processing asynchronous responses to user requests and the user is waiting for fulfillment of a Future object. A condition is perfect in this case. The future implementation is waiting for the condition and the server signals its completion.

    In the old days, we would use wait() and notify(), but that was not a very robust (or trivially safe) mechanism. The Lock and Condition objects were designed precisely to address these shortcomings.

    (A good online resource as a starting point)

    Buy and read this book.

    I am reading through java codes to ensure it is thread safe.

    As I understand, any local variables within the method is thread safe since it belongs to the stack memory address. Any class / instance variables is not thread safe as it belongs to the heap memory is shared by other thread.

    By rule of thumb, I can put a synchronized keyword on every method which touches the class variables.

    Is there any eclipse plugin, or rules I can analyze / prevent multi-threading issues?

    I don't think there is anything that will definitively check for thread safety, there are some tools that have already been mentioned, like findbugs that will do a reasonable job of finding the obvious mistakes.

    It is very much up to the programmer to ensure that their program is not leaking variables or references into different threads and where things are used in multiple threads ensuring that each thread see's the 'correct' value.

    Design for safety before performance, you might find that it performs fine for your needs but if you put optimisation in you increase complexity and potentially failure, it might not end up being the bottleneck.

    I would recommend reading reading specifically Java Concurrency In Practice, you may also find Effective Java helpful as well.

    I have always been kind of confused by threads, and my class right now makes heavy use of them. We are using java.util.concurrent but I don't even really get the basics. UpDownLatch, Futures, Executors; these words just fly over my head. Can you guys suggest any resources to help learn what I need from the ground up?

    Thanks a lot in advance!

    Read "Java Concurrency In Practice" by Brian Goetz. Great book.

    Or Doug Lea's "Concurrent Programming In Java". Old school, terrific stuff. Pre-dates the concurrent package, but it's the basis for a lot of it.

    I'm assuming that you already went through the Java tutorial's threading chapter?

    There are many good books on threading in general, but also specifically in Java.

    For example, Java Concurrency in Practice

    enter image description here

    Or is it?
    I have a thread object from:

    Thread myThread = new Thread(pObject);
    

    Where pObject is an object of a class implementing the Runnable interface and then I have the start method called on the thread object like so:

    myThread.start();
    

    Now, my understanding is that when start() is called, the JVM implicitly (and immediately) calls the run() method which may be overridden (as it is in my case)

    However, in my case, it appears that the start() method is not called immediately (as desired) but until the other statements/methods are completed from the calling block i.e. if I had a method after the start() call like so:

    myThread.start();
    doSomethingElse();
    

    doSomthingElse() gets executed before the run() method is run at all.
    Perhaps I am wrong with the initial premise that run() is always called right after the start() is called. Please help! The desired again is making executing run() right after start(). Thanks.

    You've started a new thread. That thread runs in parallel to the thread that started it so the order could be:

    pObject.run();
    doSomethingElse();
    

    or

    doSomethingElse();
    pObject.run();
    

    or, more likely, there will be some crossover. pObject.run() may run in the middle of doSomethingElse() or vice versa or one will start before the other finishes and so on. It's important to understand this and understand what is meant by an atomic operation or you will find yourself with some really hard-to-find bugs.

    It's even more complicated if two or more threads access the same variables. The value in one may never be updated in one thread under certain circumstances.

    I highly suggest:

    1. You don't make your program multi-threaded unless you absolutely need to; and

    2. If you do, buy and read from cover to cover Brian Goetz's Java Concurrency in Practice.

    please let me know a java multithread application which i can refer ( source ) and debug to understand how multithreading actually works in java ?

    Sun has a decent tutorial. But in all honestly, multithreaded programming is exremely difficult. There is a well regarded book, Java Concurrency in Practice. If you really want to learn how to take advantage of multiple cores, look into clojure or scala.

    There are certain algorithms whose running time can decrease significantly when one divides up a task and gets each part done in parallel. One of these algorithms is merge sort, where a list is divided into infinitesimally smaller parts and then recombined in a sorted order. I decided to do an experiment to test whether or not I could I increase the speed of this sort by using multiple threads. I am running the following functions in Java on a Quad-Core Dell with Windows Vista.

    One function (the control case) is simply recursive:

    // x is an array of N elements in random order
    public int[] mergeSort(int[] x) {
        if (x.length == 1) 
            return x;
    
        // Dividing the array in half
        int[] a = new int[x.length/2];
        int[] b = new int[x.length/2+((x.length%2 == 1)?1:0)];
        for(int i = 0; i < x.length/2; i++) 
            a[i] = x[i];
        for(int i = 0; i < x.length/2+((x.length%2 == 1)?1:0); i++) 
            b[i] = x[i+x.length/2];
    
        // Sending them off to continue being divided
        mergeSort(a);
        mergeSort(b);
    
        // Recombining the two arrays
        int ia = 0, ib = 0, i = 0;
        while(ia != a.length || ib != b.length) {
            if (ia == a.length) {
                x[i] = b[ib];
                ib++;
            }
            else if (ib == b.length) {
                x[i] = a[ia];
                ia++;
            }
            else if (a[ia] < b[ib]) {
                x[i] = a[ia];
                ia++;
            }
            else {
                x[i] = b[ib];
                ib++;
            }
            i++;
        }
    
        return x;
    }
    

    The other is in the 'run' function of a class that extends thread, and recursively creates two new threads each time it is called:

    public class Merger extends Thread
    {
        int[] x;
        boolean finished;
    
        public Merger(int[] x)
        {
            this.x = x;
        }
    
        public void run()
        {
            if (x.length == 1) {
                finished = true;
                return;
            }
    
            // Divide the array in half
            int[] a = new int[x.length/2];
            int[] b = new int[x.length/2+((x.length%2 == 1)?1:0)];
            for(int i = 0; i < x.length/2; i++) 
                a[i] = x[i];
            for(int i = 0; i < x.length/2+((x.length%2 == 1)?1:0); i++) 
                b[i] = x[i+x.length/2];
    
            // Begin two threads to continue to divide the array
            Merger ma = new Merger(a);
            ma.run();
            Merger mb = new Merger(b);
            mb.run();
    
            // Wait for the two other threads to finish 
            while(!ma.finished || !mb.finished) ;
    
            // Recombine the two arrays
            int ia = 0, ib = 0, i = 0;
            while(ia != a.length || ib != b.length) {
                if (ia == a.length) {
                    x[i] = b[ib];
                    ib++;
                }
                else if (ib == b.length) {
                    x[i] = a[ia];
                    ia++;
                }
                else if (a[ia] < b[ib]) {
                    x[i] = a[ia];
                    ia++;
                }
                else {
                    x[i] = b[ib];
                    ib++;
                }
                i++;
            }
    
            finished = true;
        }
    }
    

    It turns out that function that does not use multithreading actually runs faster. Why? Does the operating system and the java virtual machine not "communicate" effectively enough to place the different threads on different cores? Or am I missing something obvious?

    As others said; This code isn't going to work because it starts no new threads. You need to call the start() method instead of the run() method to create new threads. It also has concurrency errors: the checks on the finished variable are not thread safe.

    Concurrent programming can be pretty difficult if you do not understand the basics. You might read the book Java Concurrency in Practice by Brian Goetz. It explains the basics and explains constructs (such as Latch, etc) to ease building concurrent programs.

    what is the difference b/w intrinsic locking, client side locking & extrinsic locking ?

    What is the best way to create a thread safe class ?

    which kind of locking is prefered & why ?

    I would highly recommend you to read "Java Concurrency In Practice" by Brian Goetz. It is an excellent book that will help you to understand all the concepts about concurrency!

    About your questions, I am not sure if I can answer them all, but I can give it a try. Most of the times, if the question is "what is the best way to lock" etc, the answer is always it depends on what problem you try to solve.

    Question 1:

    What you try to compare here are not exactly comparable;

    Java provides a built in mechanism for locking, the synchronized block. Every object can implicitly act as a lock for purposes of synchronization; these built-in locks are called intrinsic locks.

    What is interesting with the term intrinsic is that the ownership of a lock is per thread and not per method invocation. That means that only one thread can hold the lock at a given time. What you might also find interesting is the term reentrancy, which allows the same thread to acquire the same lock again. Intrinsic locks are reentrant.

    Client side locking, if I understand what you mean, is something different. When you don't have a thread safe class, your clients need to take care about this. They need to hold locks so they can make sure that there are not any race conditions.

    Extrinsic locking is, instead of using the built in mechanism of synchronized block which gives you implicit locks to specifically use explicit locks. It is kind of more sophisticate way of locking. There are many advantages (for example you can set priorities). A good starting point is the java documentation about locks

    Question 2: It depends :) The easiest for me is to try to keep everything immutable. When something is immutable, I don't need to care about thread safety anymore

    Question 3: I kind of answered it on your first question

    How to manage thread count with respect to available memory in Java. That means, I want to control the count of running threads, by coding, with respect to memory available in the server. Any types of suggestion, tips, tutorial, lib is welcome.

    Yes use executorService. In Java Concurrency in Practice it is actually recommended to set the thread count based on the number of processors. I think the formula was thread count = number of processors + one, but I may remember wrong...

    I am new to multithreading, and get to know about the functionality of wait, notify and notifyAll. I want three threads to execute one after another and print alphabets from A to Z. I have tried below code and it seems working also, but I doubt if this is the best possible way to tackle the problem. Is there any other way, I can make it more simple and better ? It seems some portion of my code is repeating.

    package demo.threading;
    
    class Flags {
    
        boolean flagA = true;
        boolean flagB = false;
        boolean flagC = false;
    
    }
    
    class Container {
    
        Flags flags = new Flags();
        int charVal = (int) 'A';
    
        void producer1() {
    
            try {
                while (charVal <= (int) 'Z') {
                    synchronized (this) {
                        if (!flags.flagA)
                            wait();
                        else {
                            System.out.println(Thread.currentThread().getName() + " Produced : " + (char) charVal);
                            flags.flagA = false;
                            flags.flagB = true;
                            charVal++;
                            notifyAll();
                            Thread.sleep(1000);
                        }
                    }
                }
            } catch (InterruptedException ex) {
                ex.printStackTrace();
            }
    
        }
    
        void producer2() {
    
            try {
                while (charVal <= (int) 'Z') {
                    synchronized (this) {
                        if (!flags.flagB)
                            wait();
                        else {
                            System.out.println(Thread.currentThread().getName() + " Produced : " + (char) charVal);
                            flags.flagB = false;
                            flags.flagC = true;
                            charVal++;
                            notifyAll();
                            Thread.sleep(1000);
                        }
                    }
                }
            } catch (InterruptedException ex) {
                ex.printStackTrace();
            }
        }
    
        void producer3() {
    
            try {
                while (charVal <= (int) 'Z') {
                    synchronized (this) {
                        if (!flags.flagC)
                            wait();
                        else {
                            System.out.println(Thread.currentThread().getName() + " Produced : " + (char) charVal);
                            flags.flagC = false;
                            flags.flagA = true;
                            charVal++;
                            notifyAll();
                            Thread.sleep(1000);
                        }
                    }
                }
            } catch (InterruptedException ex) {
                ex.printStackTrace();
            }
        }
    }
    
    public class Main {
        public static void main(String[] args) {
    
            Container container = new Container();
    
            Thread t1 = new Thread(() -> container.producer1(), "Thread 1");
            Thread t2 = new Thread(() -> container.producer2(), "Thread 2");
            Thread t3 = new Thread(() -> container.producer3(), "Thread 3");
    
            t1.start();
            t2.start();
            t3.start();
    
        }
    }
    

    Output should be :

    Thread 1 Produced : A
    Thread 2 Produced : B
    Thread 3 Produced : C
    Thread 1 Produced : D
    Thread 2 Produced : E
    Thread 3 Produced : F
    

    As pointed out before, if you want to do this "one after another", you actually don't need multiple threads. However, you can achieve this by using a Semaphore:

    int numberOfThreads = 3;
    Semaphore semaphore = new Semaphore(1);
    
    for (int i = 1; i <= numberOfThreads; i++) {
        new Thread(() -> {
            try {
                semaphore.acquire();
                for (char c : "ABCDEFGHIJKLMNOPQRSTUVWXYZ".toCharArray()) {
                    System.out.println(Thread.currentThread().getName() 
                            + " produced: " + c + ".");
                }
            } catch (InterruptedException e) {
                // NOP
            } finally {
                semaphore.release();
            }
        }, "Thread " + i).start();
    }
    

    I recommend exploring java.util.concurrent which is available since Java 5. It's a great help to keep your concurrent code concise and simple compared with Java's low-level concurrency primitives such as wait and notify. If you're really interested in that topic, Brian Goetz's "Java Concurrency in Practice" is a must-read.

    EDIT:

    public class ConcurrentAlphabet {
    
        private Thread current;
    
        public static void main(String[] args) {
            new ConcurrentAlphabet().print(3,
                    "ABCDEFGHIJKLMNOPQRSTUVWXYZ".toCharArray());
        }
    
        public void print(int numberOfThreads, char[] alphabet) {
            Thread[] threads = new Thread[numberOfThreads];
    
            for (int i = 1; i <= numberOfThreads; i++) {
                int offset = i - 1;
                threads[offset] = new Thread(() -> {
                    Thread me = Thread.currentThread();
                    Thread next = threads[(offset + 1) % numberOfThreads];
    
                    for (int index = offset; index < alphabet.length; index += numberOfThreads) {
                        synchronized (this) {
                            while (me != current) {
                                try {
                                    wait();
                                } catch (InterruptedException e) { /* NOP */ }
                            }
    
                            System.out.println(me.getName(); + " produced: " + alphabet[index] + ".");
                            current = next;
                            notifyAll();
                        }
                    }
                }, "Thread " + i);
            }
    
            current = threads[0];
    
            for (Thread t : threads) {
                t.start();
            }
        }
    
    }
    

    I can see that ReentrantLock is around 50% faster than synchronized and AtomicInteger 100% faster. Why such difference with the execution time of these three synchronization methods: synchronized blocks, ReentrantLock and AtomicInteger (or whatever class from the Atomic package).

    Are there any other popular and extended synchronizing methods aside than these ones?

    I think that you are doing a common mistake evaluating those 3 elements for comparison.

    Basically when a ReentrantLock is something that allows you more flexibility when your are synchronizing blocks compared with the synchronized key. Atomic is something that adopts a different approach based on CAS(Compare and Swap) to manage the updates in a concurrent context.

    I suggest you to read in deep a bible of concurrency for the Java platform.

    Java Concurrency in Practice - Brian Göetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes & Doug Lea

    There's a lot difference in having a deep knowledge on concurrency and know what a language can offer you to solve concurrency problems and taking advantage of multithreading.

    In terms of performance, it depends on the current scenario.

    If I have the following code

    class SomeClass {    
    ...
    public synchronized methodA() {
    ....
    }
    
    public synchronized methodB(){
    ....
    }
    }
    

    This would synchronized on the 'this' object.
    However, if my main objective here is to make sure multiple threads don't use methodA (or methodB) at the same time, but they CAN use methodA AND methodB concurrently,
    then is this kind of design restrictive? since here thread1 lock the object (monitor object associated with the object) for running methodA but meanwhile thread2 is also waiting on the object lock even though methodA and methodB can run concurrently.
    Is this understanding correct?

    If yes, is this the kind of situation where we use synchronized block on a private dummy object so that methodA and methodB can run parallely with different thread but not methodA (or methodB) with different threads.
    Thanks.

    You've answered the question yourself: use one lock object per method and you're safe.

    private final Object lockA = new Object();
    private final Object lockB = new Object();
    public void methodA() {
        synchronized(lockA){
            ....
        }
    }
    public void methodB() {
        synchronized(lockB){
            ....
        }
    }
    

    For more advanced locking mechanisms (e.g. ReentrantLock), read Java Concurrency in Practice by Brian Goetz et al. You should also read Effective Java by Josh Bloch, it also contains some items about using synchronized.

    I have a Java program that runs many small simulations. It runs a genetic algorithm, where each fitness function is a simulation using parameters on each chromosome. Each one takes maybe 10 or so seconds if run by itself, and I want to run a pretty big population size (say 100?). I can't start the next round of simulations until the previous one has finished. I have access to a machine with a whack of processors in it and I'm wondering if I need to do anything to make the simulations run in parallel. I've never written anything explicitly for multicore processors before and I understand it's a daunting task.

    So this is what I would like to know: To what extent and how well does the JVM parallel-ize? I have read that it creates low level threads, but how smart is it? How efficient is it? Would my program run faster if I made each simulation a thread? I know this is a huge topic, but could you point me towards some introductory literature concerning parallel processing and Java?

    Thanks very much!

    Update: Ok, I've implemented an ExecutorService and made my small simulations implement Runnable and have run() methods. Instead of writing this:

    Simulator sim = new Simulator(args); 
    sim.play(); 
    return sim.getResults(); 
    

    I write this in my constructor:

    ExecutorService executor = Executors.newFixedThreadPool(32);
    

    And then each time I want to add a new simulation to the pool, I run this:

    RunnableSimulator rsim = new RunnableSimulator(args); 
    exectuor.exectue(rsim); 
    return rsim.getResults(); 
    

    The RunnableSimulator::run() method calls the Simulator::play() method, neither have arguments.

    I think I am getting thread interference, because now the simulations error out. By error out I mean that variables hold values that they really shouldn't. No code from within the simulation was changed, and before the simulation ran perfectly over many many different arguments. The sim works like this: each turn it's given a game-piece and loops through all the location on the game board. It checks to see if the location given is valid, and if so, commits the piece, and measures that board's goodness. Now, obviously invalid locations are being passed to the commit method, resulting in index out of bounds errors all over the place.

    Each simulation is its own object right? Based on the code above? I can pass the exact same set of arguments to the RunnableSimulator and Simulator classes and the runnable version will throw exceptions. What do you think might cause this and what can I do to prevent it? Can I provide some code samples in a new question to help?

    You can also see the new fork join framework by Doug Lea. One of the best book on the subject is certainly Java Concurrency in Practice. I would strong recommend you to take a look at the fork join model.

    I'm looking for a good online introduction to memory barriers and the usual pitfalls in Java code:

    • Using synchronized too often or not often enough
    • When to use volatile and final
    • Double checked locking
    • etc.

    I'd be especially interested in code which shows the behavior and/or examples how to solve common problems (like creating a map that several threads can access and where values are added lazily).

    I know you said online, but Java Concurrency In Practice is the java concurrency guide these days.

    I'm trying to implement multithreading in my Java GUI application to free up the interface when a couple of intensive methods are run. I'm primarily from a C# development background and have used Threads in that environment a couple of times, not having much difficulty of it all really.

    Roughly:

    C#

    • Create a Thread object
    • Assign it a method to start from
    • Start thread

    Now onto the Java app itself, it's a GUI application that has a few buttons that perform differrent actions, the application plays MIDI notes using the MIDI API and I have functions such as play, stop and adding individual notes. (A key thing to note is that I do not play MIDI files but manually create the notes/messages, playing them through a track).

    There are three particular operations I want to run in their own thread

    1. Play stored MIDI notes
    2. Display a list of instruments via a text box
    3. Generate 100 random notes

    I have a class called MIDIControl that contains all of the functionality necessary such as the actual operations to play,stop and generate the messages I need. There is an instance of this object created in the FooView.Java class for the GUI form itself, this means for example:

    1. Press "Generate"
    2. Event handler performs the "GenerateNotes" method in the FooView.Java class
    3. This method then performs the "Generate" method in the MIDIControl instance

    I've looked at implementing threads through Java and from what I've seen it's done in a different manner to the C# method, can anybody explain to me how I could implement threads in my situation?

    I can provide code samples if necessary, thanks for your time.

    Java Concurrency in Practice is your guide. Pls also have a look at SwingWorker. Remember that all UI related changes (either component model or its properties) should always be done on Event Dispatch Thread.

    I'm using a service that reads messages from Kafka and pushes it into Cassandra.

    I'm using a threaded architecture for the same.

    There are say, k threads consuming from Kafka topic. These write into a queue, declared as:

    public static BlockingQueue<>
    

    Now there are a number of threads, say n, which write into Cassandra. Here is the code that does that:

    public void run(){
        LOGGER.log(Level.INFO, "Thread Created: " +Thread.currentThread().getName());
        while (!Thread.currentThread().isInterrupted()) {
            Thread.yield();
            if (!content.isEmpty()) {
                try {
                    JSONObject msg = content.remove();
                    // JSON
                    for(String tableName : tableList){
                        CassandraConnector.getSession().execute(createQuery(tableName, msg));
                    }
                } catch (Exception e) {
    
                }
            }
        }
    }
    

    content is the BlockingQueue used for read-write operations.

    I'm extending the Thread class in the implementation of threading and there are a fixed number of threads that continue execution unless interrupted.

    The problem is, this is using too much of CPU. Here is the first line of top command:

      PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
    46232 vishran+  20   0 3010804 188052  14280 S 137.8  3.3   5663:24 java
    

    Here is the output of strace on a thread of this process:

    strace -t -p 46322
    Process 46322 attached
    15:18:47 sched_yield()                  = 0
    15:18:47 sched_yield()                  = 0
    15:18:47 sched_yield()                  = 0
    15:18:47 sched_yield()                  = 0
    15:18:47 sched_yield()                  = 0
    15:18:47 sched_yield()                  = 0
    15:18:47 sched_yield()                  = 0
    15:18:47 sched_yield()                  = 0
    15:18:47 sched_yield()                  = 0
    15:18:47 sched_yield()                  = 0
    15:18:47 sched_yield()                  = 0
    15:18:47 sched_yield()                  = 0
    15:18:47 sched_yield()                  = 0
    15:18:47 sched_yield()                  = 0
    15:18:47 sched_yield()                  = 0
    ....and so on
    

    Why I am using Thread.yield(), is because of this

    If you want any other information for debugging, please let me know.

    Now the question is, how can CPU utilization be minimized?

    From the looks of your code it seems that your consumer threads are always checking for content available. Therefore, your threads are always running and never iddle (waiting for someone to notify them), therefore your CPU is always doing something, even if it is always yielding the thread the current thread.

    while (!Thread.currentThread().isInterrupted()) { Thread.yield(); if (!content.isEmpty()) {

    You are clearly tring to solve the producer-consumer issue that many of us faced somewhere over our programming careers.

    What you're currently doing is having the consumer proactively continually checking if it has something to consume.

    The least and easiest CPU intensive way of solving it is:

    1. Have the producer signal the consumer that it has produced something.

    Check out this example as it contains a simplest way to do it. You may want to revisit Java Concurrency in Practice for more profound help.

    In the following code (copied from Java Concurrency in Practice Chapter 2, section 2.5, Listing 2.8):

    @ThreadSafe
    public class CachedFactorizer implements Servlet {
        @GuardedBy("this") private BigInteger lastNumber;
        @GuardedBy("this") private BigInteger[] lastFactors;
        @GuardedBy("this") private long hits;
        @GuardedBy("this") private long cacheHits;
    
        public synchronized long getHits() { return hits; }
    
        public synchronized double getCacheHitRatio() {
            return (double) cacheHits / (double) hits;
        }
    
        public void service(ServletRequest req, ServletResponse resp) {
            BigInteger i = extractFromRequest(req);
            BigInteger[] factors = null;
            synchronized (this) {
                ++hits;
                if (i.equals(lastNumber)) {
                    ++cacheHits;
                    factors = lastFactors.clone(); // questionable line here
                }
            }
            if (factors == null) {
                factors = factor(i);
                synchronized (this) {
                    lastNumber = i;
                    lastFactors = factors.clone(); // and here
                }
            }
            encodeIntoResponse(resp, factors);
        }
    }
    

    why the factors, lastFactors arrays are cloned? Can't it be simply written as factors = lastFactors; and lastFactors = factors;? Just because the factors is a local variable and it is then passed to encodeIntoResponse, which can modify it?

    Hope the question is clear. Thanks.

    Is the following code threadsafe ?

        public static Entity getInstance(){
    //the constructor below is a default one.
         return new Entity();
        }
    

    Thread safety is about access to shared data between different threads. The code in your example doesn't access shared data by itself, but whether it's thread-safe depends on whether the constructor accesses data that could be shared between different threads.

    There are a lot of subtle and hard issues to deal with with regard to concurrent programming. If you want to learn about thread safety and concurrent programming in Java, then I highly recommend the book Java Concurrency in Practice by Brian Goetz.

    It boils down to one thread submitting job via some service. Job is executed in some TPExecutor. Afterwards this service checks for results and throw exception in original thread under certain conditions (job exceeds maximum number of retries, etc.). Code snippet below roughly illustrate this scenario in legacy code:

    import java.util.concurrent.CountDownLatch;
    
    public class IncorrectLockingExample {
    
    private static class Request {
    
        private final CountDownLatch latch = new CountDownLatch(1);
    
        private Throwable throwable;
    
        public void await() {
            try {
                latch.await();
            } catch (InterruptedException ignoredForDemoPurposes) {
            }
        }
    
        public void countDown() {
            latch.countDown();
        }
    
        public Throwable getThrowable() {
            return throwable;
        }
    
        public void setThrowable(Throwable throwable) {
            this.throwable = throwable;
        }
    
    }
    
    private static final Request wrapper = new Request();
    
    public static void main(String[] args) throws InterruptedException {
    
        final Thread blockedThread = new Thread() {
            public void run() {
                wrapper.await();
                synchronized (wrapper) {
                    if (wrapper.getThrowable() != null)
                        throw new RuntimeException(wrapper.getThrowable());
                }
            }
        };
    
        final Thread workingThread = new Thread() {
            public void run() {
                wrapper.setThrowable(new RuntimeException());
                wrapper.countDown();
    
            }
        };
    
        blockedThread.start();
        workingThread.start();
    
        blockedThread.join();
        workingThread.join();
    }
    

    }

    Sometimes, (not reproducible on my box, but happens on 16 core server box) exception isn't getting reported to original thread. I think this is because happens-before is not forced(eg. 'countDown' happens before 'setThrowable') and program continues to work(but should fail). I would appreciate any help about how to resolve this case. Constraints are: release in a week, minimum impact on existing codebase is needed.

    The code above (as now updated) should work as you expected without the use of further synchronisation mechanisms. The memory barrier and its corresponding 'happens-before' relationship is enforced by the use of the CountDownLatch await() and countdown() methods.

    From the API docs:

    Actions prior to "releasing" synchronizer methods such as Lock.unlock, Semaphore.release, and CountDownLatch.countDown happen-before actions subsequent to a successful "acquiring" method such as Lock.lock, Semaphore.acquire, Condition.await, and CountDownLatch.await on the same synchronizer object in another thread.

    If you are dealing with concurrency on a regular basis get yourself a copy of 'Java Concurrency in Practice', it's the Java concurrency bible and will be well worth its weight on your bookshelf :-).

    I've programmed in a number of languages, but I am not aware of deadlocks in my code.

    I took this to mean it doesn't happen.

    Does this happen frequently (in programming, not in the databases) enough that I should be concerned about it?

    If you get a chance take a look at first few chapters in Java Concurrency in Practice.

    Deadlocks can occur in any concurrent programming situation, so it depends how much concurrency you deal with. Several examples of concurrent programming are: multi-process, multi-thread, and libraries introducing multi-thread. UI frameworks, event handling (such as timer event) could be implemented as threads. Web frameworks could spawn threads to handle multiple web requests simultaneously. With multicore CPUs you might see more concurrent situations visibly than before.

    If A is waiting for B, and B is waiting for A, the circular wait causes the deadlock. So, it also depends on the type of code you write as well. If you use distributed transactions, you can easily cause that type of scenario. Without distributed transactions, you risk bank accounts from stealing money.

    I was just wondering if it is still necessary to ensure synchronicity in an invokeLater() Runnable.

    I am encountering deadlock and need to overcome it while maintaining concurrency.

    Would this be an example of good code?:

    private String text;
    
    private void updateText()
    {
        SwingUtilities.invokeLater(new Runnable()
        {
            public void run()
            {
                synchronized(FrameImpl.this)
                {
                    someLabel.setText(text);
                }
            }
        });
    }
    

    Sorry for the rather bad example, but we must assume that text is being modified by different threads, cannot be injected, and is reliant on a correct value.

    Is this the proper solution or will I unintentionally create a deadlock problem by sending synchronized code off into an unknown context..?

    Thanks.

    A better solution would be something like this:

    public class Whatever {
        private String text;
        private final Object TEXT_LOCK = new Object();
    
        public void setText(final String newText) {
            synchronized (TEXT_LOCK) {
                text = newText;
            }
            SwingUtilities.invokeLater(new Runnable() {
                public void run() {
                    someLabel.setText(newText);
                }
            });
        }
    
        public String getText() {
            synchronized (TEXT_LOCK) {
                return text;
            }
        }
    }
    

    This will ensure that if two threads try to call setText concurrently then they will not clobber each other. The first thread in will set the value of text and enqueue a UI update with that value. The second thread will also set the value of text and enqueue a second UI update.

    The end result is that the UI will eventually show the most recent text value, but the internal text variable will immediately contain the most recent value.

    A couple of notes:

    1. Using a seperate lock object (i.e. TEXT_LOCK) means you are not vulnerable to code somewhere else locking the monitor on the Whatever instance and inadvertently causing a deadlock. Best to always keep tight control of your lock objects. It's also best to minimize the size of your synchronized blocks.
    2. You could make the whole setText method synchronized, subject to the caveat that it does make you potentially vulnerable to deadlock as above.
    3. Reading the value of text also needs to be synchronized even though Strings are immutable. There are subtleties to the Java memory model that mean you always need to synchronize around variables that can be read/written by multiple threads.

    Check out Brian Goetz's Java Concurrency in Practice for a great dive into the tricky parts of concurrency (including the memory model weirdness).

    A common way of gaining access to a field is to synchronize the getters and setters. A simple example with an int would look like:

    private int foo = 0;
    public synchronized int get(){return this.foo;}
    public synchronized void set(int bar){ this.foo = bar;}
    

    Now, while this is a safe way of making the access thread safe, it also reveals that only one thread can read foo at a time.

    If many threads where to read foo very often, and only sometimes update this variable, it would be a big waste. The getter instead could be called by multiple threads simultaneously without any problem.

    Are there any established patterns about how to deal with this? Or how would you get around this in the most elegant way?

    If you are just setting and getting the variable: Then you can use volatile and remove synchronized method.

    If you are doing any operations on the integer like addition you should use AtomicInteger.

    EDIT:

    If there is a scenario that the field is read multiple times and updated few times then there is a pattern called IMMUTABLE. This is one of the way to achieve thread safety.

    class ImmutableClass{
            private final int a;
    
            public ImmutableClass(int a) {
                this.a  = a;
            }
    
            public int getA(){
                return a;
            }
    
            /* 
             * No setter methods making it immutable and Thread safe
             */
        }
    

    For more detailed knowledge on Immutability, Java Concurrency In practice is the best resource I would suggest you to read.

    For more advanced ways: There is a Read/Write lock

    Am writing a multithreading application that has several threads(approxiamately 25) with each thread performing a specific process and then updating the database in the which then gives the next thread the permission to process another process and do the same. Basically, thread1 does process then updates db as complete then when thread two reads the db as complete it begins processing and the process continues until thread 25. Anyone know how this is possible in java?

    Your question is incredibly general but the approach I'd take would be something like:

    1. designate one thread as the controller thread. It's job is to listen for the worker threads to complete their processing. The simplest way to do with is with a semaphore object and the wait/notify methods - the controller thread would take a lock on the semaphore and then call wait.

    2. create your worker threads, each with its own semaphore object against which each thread takes a lock on and again calls wait.

    3. the trigger to start the processing (this could be the application running, the user clicking a button, etc) obtains a lock on the controller's semaphore and calls notify against it waking the controller thread. The controller's job is to pick one of the worker threads from the pool, obtain a lock on its semaphore and the call notify causing the worker to awake. The controller then calls wait on its own semaphore.

    4. the worker thread can then read the database, does the processing and write back to the database before it calls notify on the controller's semaphore causing the process to start again with the controller calling notify on one of the worker threads' *semaphore*s and wait against its own .

    Finally a word of warning, this is a very brief outline of what's required to implement the general behaviour you've described. Threading is possbily the most misunderstood topics in computer science imho and very very easy to get wrong. Before leaping into a multi-threaded system make sure at the very least you've read Brian Goatz's - Java Concurrency In Practice

    A quote from #JCIP :

    "Since a ConcurrentHashMap cannot be locked for exclusive access, we cannot use client-side locking to create new atomic operations such as put-if-absent, as we did for Vector"

    Why we can't just acquire the lock in order to implement additional atomic methods and keep the collection thread-safe (like synchronized collections returned by Collections.synchronizedxxx factory) :

    Why? Because the implementation does not support it. Straight from the ConcurrentHashMap JavaDocs:

    There is not any support for locking the entire table in a way that prevents all access

    ...which is, by definition, "exclusive access."

    Can anyone suggest a good documentation/tutorial/book about the Future interface in Java?

    Concurrent Programming in Java(TM): Design Principles and Patterns (2nd Edition) by Doug Lea. This is the book by the author of java.util.concurrent package. Java Concurrency in Practice is a very good book, too.

    Can somebody tell me how I can find out "how many threads are in deadlock condition" in a Java multi-threading application? What is the way to find out the list of deadlocked threads?

    I heard about Thread Dump and Stack Traces, but I don't know how to implement it.

    • I also want to know what new features have been introduced in Java 5 for Threading?

    Please let me know with your comments and suggestions.

    If you want to learn about the new concurrent features in Java 5 you could do a lot worse than getting a copy of Java Concurrency in Practice by Brian Goetz (Brian Goetz and a number of the coauthors designed the Java 5 concurrency libraries). It is both highly readable and authoritative , and combining practical examples and theory.

    The executive summary of the new concurrent utilities is as follows:

    • Task Scheduling Framework - The Executor framework is a framework for standardizing invocation, scheduling, execution, and control of asynchronous tasks according to a set of execution policies. Implementations are provided that allow tasks to be executed within the submitting thread, in a single background thread (as with events in Swing), in a newly created thread, or in a thread pool, and developers can create of Executor supporting arbitrary execution policies. The built-in implementations offer configurable policies such as queue length limits and saturation policy which can improve the stability of applications by preventing runaway resource consumption.
    • Concurrent Collections - Several new Collections classes have been added, including the new Queue and BlockingQueue interfaces, and high-performance, concurrent implementations of Map, List, and Queue.
    • Atomic Variables - Classes for atomically manipulating single variables (primitive types or references), providing high-performance atomic arithmetic and compare-and-set methods. The atomic variable implementations in java.util.concurrent.atomic offer higher performance than would be available by using synchronization (on most platforms), making them useful for implementing high-performance concurrent algorithms as well as conveniently implementing counters and sequence number generators.
    • Synchronizers - General purpose synchronization classes, including semaphores, mutexes, barriers, latches, and exchangers, which facilitate coordination between threads.
    • Locks - While locking is built into the Java language via the synchronized keyword, there are a number of inconvenient limitations to built-in monitor locks. The java.util.concurrent.locks package provides a high-performance lock implementation with the same memory semantics as synchronization, but which also supports specifying a timeout when attempting to acquire a lock, multiple condition variables per lock, non-lexically scoped locks, and support for interrupting threads which are waiting to acquire a lock.
    • Nanosecond-granularity timing - The System.nanoTime method enables access to a nanosecond-granularity time source for making relative time measurements, and methods which accept timeouts (such as the BlockingQueue.offer, BlockingQueue.poll, Lock.tryLock, Condition.await, and Thread.sleep) can take timeout values in nanoseconds. The actual precision of System.nanoTime is platform-dependent.

    Currently I have a Thread running a Socket listening for connections. When it receives a connection, it needs to upload data gathered in the main thread (i.e. grab data from main thread). However I pass an instance of the Object, but it's never updated with the data that's collected while waiting for a connection.

    Is there a proper way to do this? I've googled around and can't seem to find a concrete answer.

    Could someone point me in the right direction?


    Hopefully this makes sense, but i'll try to explain more with an examples.

    class MainThread {
        private void MainThread() {
            SomeObj obj = new SomeObj("DATA Needed");
    
            SecondThread second = new SecondThread(obj);
            second.start();
        }
    }
    
    class SecondThread extends Thread {
        SomeObj obj;
    
        public void SecondThread(Object obj) {
        this.obj = obj;
        }
        public void run() {
    
        //Listening for connection
        //Connection get!
        //Get updated data (Object obj) from main thread.
        //Upload
        }
    }
    

    I appreciate any help you can give me. Please let me know if I am approaching this completely wrong! I would rather learn AND get answers than just get answers.

    Thanks so much!

    There is a limited set of events that ensure a write in one thread is visible in another. Thread creation is one of them, so any data written into obj initially should be available in the second thread.

    One option would be to synchronize on obj. If the main thread only modified it by calling its synchronized methods and the second thread got the data from an obj synchronized method the main thread writes would be visible in the second thread.

    If you really want to learn about multi-threading in Java, I recommend Java Concurrency in Practice

    From the book Java Concurrency in Practice , Chapter 12.1 Testing for correctness, specifically in sub-section 12.1.3 Testing safety(where the author wants to set up test cases for testing data-race safety of a Bounded Buffer class)

    To ensure that your test actually tests what you think it does, it is important that the checksums themselves not be guessable by the compiler. It would be a bad idea to use consecutive integers as your test data because then the result would always be the same, and smart compiler could conceivably just precompute it.

    To avoid this problem, test data should be generated randomly,but many otherwise effective tests are compromised by a poor choice of random number generator(RNG). Random number generation can create couplings between classes and timing artifacts because most random number generator classes are thread safe and therefore introduce additional synchronization.Giving each thread its own RNG allows a non-thread-safe RNG to be used.

    I do not understand the point made by the author against using Random number generators for generating the test inputs. Specifically the line Random number generation can create couplings between classes and timing artifacts is not clear to me.

    1. Which classes and timing artifacts is he referring to here?
    2. What kind of couplings the RNG can create?

    Random number generation can create couplings between classes and timing artifacts is not clear to me.

    This is more clear by taking into account the next sentence:

    because most random number generator classes are thread safe and therefore introduce additional synchronization

    It's the memory synchronization that may change the timing of your program. If you look into Random, you can see that it uses an AtomicInteger under the covers so using it will cause read and write memory barriers as part of the generation of the test data which may change how the other threads see data and the timing of your application overall.

    Which classes and timing artifacts is he referring to here?

    Any class that uses threads and relies on memory synchronization may be affected. Basically all threads and classes that they call.

    What kind of couplings the RNG can create?

    As @Bill the Lizard commented on, the book is saying that by using a RNG, the timing of the program then is relying on or affected by the RNG synchronization.

    The real lesson here is that the test data you inject into program should not change the timing of your program if possible. It is often difficult and can be impossible but the goal is to simulate the application behavior (timing, input, output, ...) as much as possible in the test.

    In terms of a solution, you could use another simple random algorithm that was not synchronized. You could also generate a class that stored 10000 random numbers (or however many you need) beforehand and then handed them out without synchronization. But by using a class in your tests that did memory synchronization, you are changing the timing of your program.

    Hi I have a GUI application that is working fine. I created a socket server. When I create a new object of the Server class in program the GUI application stops responding.

    This is my server class. If I do

    Server s = new Server();
    

    in my main application it stops working. How should I add it? Making a new thread? I tried

    Thread t = new Thread(new Server());
    t.start();
    

    but the problem persisted. Please, I'll appreciate your help.

    package proj4;
    
    import java.net.*; 
    import java.io.*; 
    
    public class Server implements Runnable { 
        ServerSocket       serverSocket = null;
        Socket             clientSocket = null;
        ObjectOutputStream out          = null;
        ObjectInputStream  in           = null;
        int                port;
        static int         defaultPort  = 30000;
        boolean            isConnected  = false;
        Thread             thread;
        DataPacket         packet       = null;
    
        public Server(int _port) {
            try {
                serverSocket = new ServerSocket(_port);
                serverSocket.setSoTimeout(1000*120);  //2 minutes time out     
                isConnected = true;
                System.out.println("server started successfully");
                thread = new Thread(this);
                thread.setDaemon(true);
                //thread.run();
            } catch (IOException e) {
                System.err.print("Could not listen on port: " + port);
                System.exit(1);
            }
            try {
                System.out.println("Waiting for Client");
                clientSocket = serverSocket.accept();
                System.out.println("Client Connected");
                thread.run();
            } catch (IOException e) {
                System.err.println("Accept failed.");
                System.exit(1);
            }
            try {
                out = new ObjectOutputStream(clientSocket.getOutputStream());
                System.out.println("output stream created successfully");
            } catch (IOException e) {
                e.printStackTrace();
            }
            try {
                in = new ObjectInputStream(clientSocket.getInputStream());
                System.out.println("input stream created successfully");
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    
        public Server() {
            this(defaultPort); //server listens to port 30000 as default
        }
    
        public void run() {
            System.out.println("Thread running, listening for clients");//debugging purposes
            while (isConnected) {
                try {
                    packet = this.getData();
                    Thread.sleep(0);
                } catch(InterruptedException e) {
                    e.printStackTrace();
                }
            }
        } 
    
        public DataPacket getData() {
            try {
                packet = (DataPacket)in.readObject();
            } catch (Exception ex)  {
                System.out.println(ex.getMessage());
            }
            return packet;
        }
    
        public void sendData(DataPacket dp) {
            try {
                out.writeObject(dp);
            } catch (IOException e) {
                e.printStackTrace();
            } 
            try {
                out.flush();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    
        public void closeConnection() throws IOException {
            out.close(); 
            in.close(); 
            clientSocket.close(); 
            serverSocket.close(); 
        }
    } 
    

    Your Server constructor blocks, potentially indefinitely, in accept().

    Two things about Swing programs:

    1. Never do any long task in the Swing event thread, and,
    2. Never do manipulate any Swing object outside the Swing event thread unless the method being used is explicitly documented as thread-safe.

    This means that if the server is being started from the Swing event thread -- that is, if it is being started in response to a button click or the like -- then yes you must spawn another thread for your Server object. Otherwise you guarantee that the Swing event thread will be blocked until your thread exits.

    You say that your application still stops responding even when you spawn another thread for your server? Ensure that you're calling Thread.start() and not run(), or you will accidentally still block yourself by running the "new Thread" actually in your own Thread.

    NOTES:

    1. I see that you do a Thread.sleep(0); in your run() loop. This is not guaranteed to do anything whatsoever. If you have a single CPU machine, this may be fairly be implemented as a no-op, allowing the same thread to keep running.
    2. You really want isConnected to be volatile -- otherwise there is no guarantee that changes to this variable will be seen by any thread other than the one where it is changed.
    3. You don't set isConnected to false, anywhere, so your run() will run until the JVM is stopped or until that Thread takes a RuntimeException.
    4. It is discouraged to start Threads in constructors. (See Java Concurrency In Practice.)
    5. You don't want to accept on your ServerSocket until you are in your Thread's run() method! Otherwise your constructor will block waiting for a connection and will not return control to the event thread!
    6. You have the following code in your constructor:

    your code is:

    thread = new Thread(this);
    thread.setDaemon(true);
    //thread.run();
    

    When you had thread.run() not commented out, you were not starting a new Thread! To do that, you need to do thread.start(). Instead, you were running this new Thread (which will never stop, for reason #3 above) in the same thread that invoked the constructor. The way your code is written right now, all IOExceptions are logged, but otherwise swallowed. You probably want to set isConnected to false on any IOException, as well as in closeConnection().

    How to determine part of what Java code needs to be synchronized? Are there any unit testing technics?

    Samples of code are welcome.

    Code needs to be synchronized when there might be multiple threads that work on the same data at the same time.

    Whether code needs to be synchronized is not something that you can discover by unit testing. You must think and design your program carefully when your program is multi-threaded to avoid issues.

    A good book on concurrent programming in Java is Java Concurrency in Practice.

    I am currently learning basics of Threads in Java and I am trying to write a simple Thread Group program. I wrote it same as tutorial website though i'm getting different type of output. Below is my code for which i'm getting different output.

    public class ThreadGroupDemo implements Runnable {
    
        @Override
        public void run() {
            System.out.println(Thread.currentThread().getName());
            // get the name of the current thread.
        }
    
        public static void main(String[] args) {
            ThreadGroupDemo runnable = new ThreadGroupDemo();
            ThreadGroup tg1 = new ThreadGroup("Parent Group");
            // Creating thread Group.
    
            Thread t1 = new Thread(tg1, new ThreadGroupDemo(), "one");
            t1.start();
            t1.setPriority(Thread.MAX_PRIORITY);
    
            Thread t2 = new Thread(tg1, new ThreadGroupDemo(), "second");
            t2.start();
            t2.setPriority(Thread.NORM_PRIORITY);
    
            Thread t3 = new Thread(tg1, new ThreadGroupDemo(), "Three");
            t3.start();
    
            System.out.println("Thread Group name : " + tg1.getName());
            tg1.list();
        }
    
    }
    

    I am getting Output :

    Thread Group name : Parent Group
    Three
    java.lang.ThreadGroup[name=Parent Group,maxpri=10]
        second
    one
    Thread[one,10,Parent Group]
        Thread[second,5,Parent Group]
        Thread[Three,5,Parent Group]
    

    The output should be like :

    one
    two
    three
    Thread Group Name: Parent ThreadGroup
    java.lang.ThreadGroup[name=Parent ThreadGroup,maxpri=10]
        Thread[one,5,Parent ThreadGroup]
        Thread[two,5,Parent ThreadGroup]
        Thread[three,5,Parent ThreadGroup] 
    

    i am not able to understand why this happening? setting Priority can help with it?

    You can't predict the order of executions of your threads even with a level of priority. You have no control on the scheduling. It's your OS which decides.

    A good book about concurrency in Java : Java concurrency in practice

    I am currently studying concurrent programming patterns. Consider the solution to the producer consumer problem with bounded buffer using semaphores, presented on wikipedia.

    What if, at some point, the producer says: this is the last item I'm making. How could I make the program terminate?(the consumer will still wait until it is informed that there is something in the buffer).

    Similarly, what if the consumer says: I don't want to consume anymore. How can the producer be informed, so that the program exits? (the producer is waiting to have an available spot to put something).

    From Java Concurrency in Practice Book 7.2.3

    Another way to convince a producer consumer service to shut down is with a poison pill: a recognizable object placed on the queue that means "when you get this, stop."

    Go through the 7th chapter of this book Cancellation and Shutdown

    I am Java EE developer, and I want to get skills on concurrency development.
    Could you provide me some assignments, ideas, or other - just for learning and training concurrency programming?

    There's a brilliant book about Java concurrency called "Java Concurrency in Practice". I think this is the best starting point for diving deep into advanced concurrency.

    Java Concurrency in Practice (Amazon)

    I have blogged about new concurrency solutions with the Spring framework 3 and Java EE 6 here.

    It explains how to execute asynchronous methods declaratively with the @Async or the Java EE's @Asynchronous annotation.

    These annotations are just a way to abstract away the complex concurrency logic.

    You can configure Spring to use the excellent Executor class to do the concurrency logic. The Exceutor class was introduced in Java 5 and is explained well in the Java Concurrency in Practice book together with the other classes in the java.util.concurrent package.

    The article also demonstrates how to use the same Executor service in the code and by the Spring framework. Which enables you to use the same thread pool for both your programmatic concurrency logic and your concurrency logic handled by an application container.

    Else, you can learn a lot from the Java documentation. Read about all the classes in the concurrent package and especially the Executor class. This is at least my most used documetation.

    I am new to Java and the following might be obvious, but it is puzzling to me. Consider the following code:

    while(1>0){
      if(x!=0){
      //do something
      }
    }
    

    The x variable is changed in a different thread. However, the code in the if statement is never executed even when x is not zero. If I change the code by the following

    while(1>0){
      System.out.println("here");
    
      if(x!=0){
      //do something
      }
    }
    

    the code in the if statement is now executed when x is no longer zero. I suspect this has to do with the rules of the Java compiler, but it is very confusing to me. Any help clarifying this would be greatly appreciated.

    If x is changing in a different thread then you are probably seeing a side-effect of the fact that you have not synchronized access to that variable.

    The Java memory and threading model is pretty complex, so I'd recommend you get a copy of Java Concurrency in Practice by Brain Goetz and have a read.

    The short answer is to make sure that access to x is enclosed in a synchronized block:

    while (1 > 0) {
        int temp;
        synchronized (this) {
            temp = x;
        }
        if (temp != 0) {
            // Do something
        }
    }
    

    And similarly in the code that modifies x.

    Note that this example stores x in a temporary variable, because you want synchronized blocks to be as small as possible - they enforce mutual exclusion locks so you don't want to do too much in there.

    Alternatively, you could just declare x to be volatile, which will probably be sufficient for your use case. I'd suggest you go with the synchronized version because you'll eventually need to know how to use synchronized properly, so you might as well learn it now.

    I am reading the book Java Concurrency in Practice where it says,

    CyclicBarrier allows a fixed number of parties to rendezvous repeatedly at a barrier point and is useful in parallel iterative algorithms that break down a problem into a fixed number of independent subproblems.

    Can someone give an example of how it breaks down a problem into multiple independent subproblems?

    You have to break the problem down into multiple independent subproblems yourself.

    Barriers ensure that each party completes the first subproblem before any of them start on the second subproblem. This ensures that all of the data from the first subproblem is available before the second subproblem is started.

    A CyclicBarrier specifically is used when the same barrier is needed again and again when each step is effectively identical. For example, this could occur when doing any sort of multithreaded reality simulation which is done in steps. The CyclicBarrier would ensure that each thread has completed a given step before all threads will begin the next step.

    I am seeing a lot of classes being added to Java which are not thread safe.

    Like StringBuilder is not thread safe while StringBuffer was and StringBuilder is recoomended over Stringbuffer.

    Also various collection classes are not thread safe.

    Isn't being thread safe a good thing ?

    Or i am just stupid and don't yet understand the meaning of being thread safe ?

    Because thread safety makes things slower, and not everything has to be multi-threaded.

    Consider reading this article to find out basics about thread safety :

    http://en.wikipedia.org/wiki/Thread_safety

    When you comfortable enough with the threads/or not, consider reading this book, it has great reviews :

    http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601

    I have read article concerning atomic operation in Java but still have some doubts needing to be clarified:

    int volatile num;
    public void doSomething() {
      num = 10;  // write operation
      System.out.println(num)   // read
      num = 20;  // write
      System.out.println(num);  // read
    }
    

    So i have done w-r-w-r 4 operations on 1 method, are they atomic operations? What will happen if multiple threads invoke doSomething() method simultaneously ?

    volatile ensures that if you have a thread A and a thread B, that any change to that variable will be seen by both. So if it at some point thread A changes this value, thread B could in the future look at it.

    Atomic operations ensure that the execution of the said operation happens "in one step." This is somewhat confusion because looking at the code 'x = 10;' may appear to be "one step", but actually requires several steps on the CPU. An atomic operation can be formed in a variety of ways, one of which is by locking using synchronized:

    • What the volatile keyword promises.
    • The lock of an object (or the Class in the case of static methods) is acquired, and no two objects can access it at the same time.

    As you asked in a comment earlier, even if you had three separate atomic steps that thread A was executing at some point, there's a chance that thread B could begin executing in the middle of those three steps. To ensure the thread safety of the object, all three steps would have to be grouped together to act like a single step. This is part of the reason locks are used.

    A very important thing to note is that if you want to ensure that your object can never be accessed by two threads at the same time, all of your methods must be synchronized. You could create a non-synchronized method on the object that would access the values stored in the object, but that would compromise the thread safety of the class.

    You may be interested in the java.util.concurrent.atomic library. I'm also no expert on these matters, so I would suggest a book that was recommended to me: Java Concurrency in Practice

    I'm just starting to dip into concurrency so bear with me if I ask some obvious/dumb things. I'm trying to take the first steps to revamp a model I have to take advantage of Java currency. Without getting into specifics, I have a portion of the model that loads some file and then when given requests it returns some corresponding data on the file. My challenge is to make this run on it's own thread now, so that while it still only processes one request at a time, it can queue up requests made other parts of the code running on their own threads.

    After trying to teach myself concurrency through the great tutorials at jenkov.com I used what I learned and basically created something a lot like a BlockingQueue where there's an object that acts as a lock where requests go in as threads that queue up, and when the current thread is finished processing it unlocks for the next in line. So threads are continually being created, put into wait, started, then eventually destroyed, as each request is a new thread.

    What I thought of now though, is instead doing it more like what I originally pictured, where there is only one thread that waits for instructions, then processes those instructions. So instead of requests coming in as threads, there's some singular thread that waits until it has a request, processes that, processes any other requests that have queued up, and if there's no more, waits again. The (supposed) advantage being that requests come in as variables/instructors and threads aren't continually being created/destroyed.

    So the question being is there an advantage to rewriting it to be more like that? I know creating/destroying threads probably doesn't create a whole lot of overhead (as long as I'm using the wait/notify functions instead of say a busy wait) but this is a type of model that has to run literally millions of iterations sometimes and even marginal gains would multiply in situations like that.

    Don't create a bunch of Threads; use an ExecutorService, initialize it with a SingleThreadExecutor, and give your users (client classes) an API they can call to submit jobs to the Executor. This gives you a lot of future flexibility by just replacing (or specializing) your executor.

    Here's a second vote for the comment: Go read "Java Concurrency In Practice" by Brian Goetz - I cannot recommend this highly enough.

    While you are waiting for your book to arrive:

    http://docs.oracle.com/javase/tutorial/essential/concurrency/executors.html http://tutorials.jenkov.com/java-util-concurrent/executorservice.html

    I'm reading the book Java concurrency in practice and when I read about the relation between immutability and thread-safety I tried to get deeper. So, I discovered that there is at least a use case in which the construction of an immutable class in Java can lead to the publishing of a non properly constructed object.

    According to this link, if the fields of the class are not declated final, the compiler could reorder the statements that needs to be done in order to construct the object. In fact, according to this link, to build an object the JVM needs to do these non-atomic operations:

    1. allocate some memory
    2. create the new object
    3. initialise its fields with their default value (false for boolean, 0 for other primitives, null for objects)
    4. run the constructor, which includes running parent constructors too
    5. assign the reference to the newly constructed object

    My question is: what about Scala? I know that Scala is based on the concurrency model of Java, so it is based on the same Java Memory Model. For example, are case classes thread-safe wrt the above construction problem?

    Thanks to all.

    I've made some deep search on Stackoverflow and on the Internet. There is not so much information about the question I've made. I found this question on SO that has an interesting answer: Scala final vs val for concurrency visibility.

    As proposed by @retronym I've used javap -p A.class to destructure a .class file containing a case class and compiled by scalac. I found that the class

    case class A(val a: Any)
    

    is compiled by the scala compiler into a corresponding Java class that declares its unique attribute a as final.

    Compiled from "A.scala"
    public class A implements scala.Product,scala.Serializable {
      // Final attribute
      private final java.lang.Object a;
      public static <A extends java/lang/Object> scala.Function1<java.lang.Object, A
    > andThen(scala.Function1<A, A>);
      public static <A extends java/lang/Object> scala.Function1<A, A> compose(scala
    .Function1<A, java.lang.Object>);
      public java.lang.Object a();
      public A copy(java.lang.Object);
      public java.lang.Object copy$default$1();
      public java.lang.String productPrefix();
      public int productArity();
      public java.lang.Object productElement(int);
      public scala.collection.Iterator<java.lang.Object> productIterator();
      public boolean canEqual(java.lang.Object);
      public int hashCode();
      public java.lang.String toString();
      public boolean equals(java.lang.Object);
      public A(java.lang.Object);
    }
    

    As we know, a case class in Scala generates automatically a bunch of utilities for us. But also a simple class like this

    class A1(val a: Any)
    

    is translated into a Java class that has a final attribute.

    Summarizing, I think we can say that a Scala class that has only val attributes is translated into a corresponding Java class that has final attributes only. Due to the JMM of the JVM, this Scala class should be thread-safe during the construction process.

    I'm trying to process multiple csv at the same time. My code looks like this :

    public class CSVMain{
    
    private static int count = 3;
    
    public static void main(String[] a){
    
        ExecutorService e = Executors.newFixedThreadPool(300);         
        for(int i=0;i<count;i++) e.execute(new WebRunner("http://some.host.com"));         
        e.shutdown();
    
    }
    
    static class WebRunner implements Runnable{
    
        private final String url;
    
        public WebRunner(String url) {
            this.url = url;
        }
    
        @Override
        public void run() {
    
            try {
    
                long now = System.currentTimeMillis();
                URL MyUrl = new URL(url);
                HttpURLConnection conn = (HttpURLConnection) MyUrl.openConnection();
                conn.connect();
    
                IOUtils.toByteArray(MyUrl.openStream());
    
                System.out.println(new DateTime().toString("HH:mm:ss,SSS") + " finish thread" + Thread.currentThread().getId() + " in " + (System.currentTimeMillis() - now));
            } catch (Exception e) {
                e.printStackTrace();
            } 
        }
    
    }
    
    }
    

    If I set the static count variable to 1, it would complete in 600-700 ms with my connection. When it's 2, I'll get around 1100-1400ms, when 3, it's 1700-1900ms and so on.

    The statistics feels sequential, not parallel.

    Am I missing something here?

    There are several points that contribute to this.

    First, you are measuring the run-time of individual Runnables, not the total run-time for the sequential runs (i.e. you run the WebRunner three times, one after the other) versus the concurrent runs (you give them to a thread pool, like you are doing here).

    Another important fact is that concurrency doesn't mean that things will execute in parallel. Concurrency is not parallelism They might, or they might not. Concurrency is also highly non-deterministic. That is, when the threads are allowed to run and for how long they run depends on a lot of things, including the operating system. Depending on the circumstances, they might even end up running sequentially (regardless of the size of your thread pool). And they might even appear to be executing in parallel, but they might do so in a round-robin fashion, without much benefit from concurrency and and with the overhead of switching. There are a lot of subtleties to concurrency. For an in-depth guide, the best resource is this book.

    Also, even if the tasks do run in parallel, there are other restrictions on performance.For ex. you might have limited network bandwidth and when the tasks run in parallel, they might end up competing for that limited resource. The same is true for both computing power and memory.

    Another very important thing is that, what you are doing is a naive version of micro benchmarking. In order to get more reliable benchmarking stats, you should probably use something like The JMH framework. Here's a relevant article on the pitfalls of naive java benchmarking and an an article on JMH

    The TL;DR; version is: do not try to assign meaning to the performance of concurrent applications without a lot of rigor.

    I think I found more bugs in my web application. Normally, I do not worry about concurrency issues, but when you get a ConcurrentModificationException, you begin to rethink your design.

    I am using JBoss Seam in conjuction with Hibernate and EHCache on Jetty. Right now, it is a single application server with multiple cores.

    I briefly looked over my code and found a few places that haven't thrown an exception yet, but I am fairly sure they can.

    The first servlet filter I have basically checks if there are messages to notify the user of an event that occurred in the background (from a job, or another user). The filter simply adds messages to the page in a modal popup. The messages are stored on the session context, so it is possible another request could pull the same messages off the session context.

    Right now, it works fine, but I am not hitting a page with many concurrent requests. I am thinking that I might need to write some JMeter tests to ensure this doesn't happen.

    The second servlet filter logs all incoming requests along with the session. This permits me to know where the client is coming from, what browser they're running, etc. The problem I am seeing more recently is on image gallery pages (where there are many requests at about the same time), I end up getting a concurrent modification exception because I'm adding a request to the session.

    The session contains a list of requests, this list appears to be being hit by multiple threads.

    @Entity
    public class HttpSession 
    {
      protected List<HttpRequest> httpRequests;
    
      @Fetch(FetchMode.SUBSELECT)
      @OneToMany(mappedBy = "httpSession")
      public List<HttpRequest> getHttpRequests()
      {return(httpRequests);}
    
      ...
    }
    
    @Entity
    public class HttpRequest
    {
      protected HttpSession httpSession;
    
      @ManyToOne(optional = false)
      @JoinColumn(nullable = false)
      public HttpSession getHttpSession()
      {return(httpSession);}
    
      ...
    }
    

    In that second servlet filter, I am doing something of the sort:

    httpSession.getHttpRequests().add(httpRequest);
    session.saveOrUpdate(httpSession);
    

    The part that errors out is when I do some comparison to see what changed from request to request:

    for(HttpRequest httpRequest:httpSession.getHttpRequests())
    

    That line there blows up with a concurrent modification exception.

    Things to walk away with: 1. Will JMeter tests be useful here? 2. What books do you recommend for writing web applications that scale under concurrent load? 3. I tried placing synchronized around where I think I need it, ie on the method that loops through the requests, but it still fails. What else might I need to do?

    I added some comments:

    I had thought about making the logging of the http requests a background task. I can easily spawn a background task to save that information. I am trying to remember why I didn't evaluate that too much. I think there is some information that I would like to have access to on the spot.

    If I made it asynchronous, that would speed up the throughput quite a bit - well I'd have to use JMeter to measure those differences.

    I would still have to deal with the concurrency issue there.

    Thanks,

    Walter

    It's been caused because the list has been modified by another request while you're still iterating over it in one request. Replacing the List by ConcurrentLinkedQueue (click link to see javadoc) should fix the particular problem.

    As to your other questions:

    1: Will JMeter tests be useful here?

    Yes, it is certainly useful to stress-test webapplications and spot concurrency bugs.

    2: What books do you recommend for writing web applications that scale under concurrent load?

    Not specific tied to webapplications, but more to concurrency in general, the book Concurrency in Practice is the most recommended one in that area. You can perfectly apply the learned things on webapplications as well, they are a perfect real world example of "heavy concurrent" applications.

    3: I tried placing synchronized around where I think I need it, ie on the method that loops through the requests, but it still fails. What else might I need to do?

    You basically need to synchronize any access to the list on the same lock. But just replacing by ConcurrentLinkedQueue is easier.

    This is listing 8.1 in Java Concurrency In Practice:

    public class ThreadDeadlock  {
       ExecutorService exec = Executors.newSingleThreadExecutor();
    
       public class RenderPageTask implements Callable<String>  {
          public String call() throws Exception  {
             Future<String> header, footer;
             header = exec.submit(new LoadFileTask("header.html"));
             footer = exec.submit(new LoadFileTask("footer.html"));
             String page = renderBody();
    
             //Will deadlock -- task waiting for result of subtask
             return header.get() + page + footer.get();
          }
       }
    }
    

    It's in

    Chapter 8: Thread Pools > Section 8.1.1 Thread starvation deadlock

    and has the caption:

    "Task that deadlocks in a single-threaded Executor. Don't do this."

    Why does this result in a deadlock? I thought header.get() is called, and then footer.get() is called, which each result appended to the string. Why wouldn't a single threaded Executor be enough to run these one after the other?

    Relevant chapter text:

    8.1.1 Thread starvation deadlock

    If tasks that depend on other tasks execute in a thread pool, they can deadlock. In a single-threaded executor, a task that submits another task to the same executor and waits for its result will always deadlock. The second task sits on the work queue until the first task completes, but the first will not complete because it is waiting for the resut of the second task. The same thing can happen in larger thread pools if all threads are executing tasks that are blocked waiting for other tasks still on the work queue. This is called thread starvation deadlock, and can occur whenever a pool task initiates an unbounded blocking wait for some resource or condition that can succeed only through the action of another pool task, such as waiting for the return value or side effect of another task, unless you can guarantee that the pool is large enough.

    ThreadDeadlock in Listing 8.1 illustrates thread starvation deadldock. RenderPageTask submits two additional tasks to the Executor o fetch the page header and footer, renders the page body, waits for the results of the header and footer tasks, and then combines the header, body, and footer into the finished page. With a single-threaded executor, ThreadDeadlock will always deadlock. Similarly, tasks coordinating amongst themselves with a barrier could also cause thread starvation deadlock if the pool is not big enough.

    The actual deadlock will occur will occur as soon as an instance of RenderPageTask is submitted to the very same executor instance where it submits its task.

    For example, add

    exec.submit(new RenderPageTask());
    

    and you will experience a deadlock.

    Of course this can be considered a problem of the surrounding code (i.e., you could simply define and document that your RenderPageTask should not be submitted to this executor instance), but a good design would avoid such pitfalls entirely.

    A possible solution for this would be to use ForkJoinPool, which uses work stealing to avoid this form of possible deadlocks.

    What would you suggest as a road map for becoming very proficient in writing multithreaded applications - beyond "tinkering"?

    I am a C# developer - would branching off into some other languages help this endeavor?

    Does the parallel addition to .NET 4.0 hide things that you should know in order to make it easier?

    • Read Joe Duffy's "Concurrent Programming on Windows". Joe is an amazing expert.
    • Investigate different approaches to concurrency on different platforms; look at Erlang, Scala etc
    • Likewise read Java concurrency books, which will have some subtly different details, but often tackle the same core issues and have some useful patterns. "Java Concurrency in Practice" is often recommended.
    • Look at the various options on .NET, including the Coordination and Concurrency Runtime and F# asynchronous computations
    • Definitely learn Parallel Extensions - it'll help a lot, and from what I've seen, a lot of very careful design work has gone into it. (It's changing somewhat for 4.0b2 though, so you may want to defer this for now.)

    Do Java classes have an instance on machine (JVM) level if they contain only static methods and fields?

    And if yes, what are the effects of static methods and fields when doing multithreading? Any rules of thumb?

    There are no such thing as "static classes" in java. There are inner static classes, but i presume that your question its not about this type of classes.

    Classes are loaded once per classloader not per Virtual Machine, this is an important diference, for example applications server like tomcat have different classloaders per application deployed, this way each application is independent (not completely independent, but better than nothing).

    The effects for multithreading are the effects of shared data structures in multithreading, nothing special in java. There are a lot of books in this subject like http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601 (centered in java) or http://pragprog.com/book/pb7con/seven-concurrency-models-in-seven-weeks (that explain difference concurrency models, really interesting book)

    Essentially, what I want to do is start all my threads, pause them all, then resume them all, using the multithreading approach. I am just looking for a simple solution to this. I'm not sure if I have to use a timer or what. Right now when I run it, the threads are like being executed in random order (I guess the PC is just randomly picking which ones it wants to run at a certain time).

    class ChoppingThread extends Thread
    {
        public void run()
        {
            for(int j=40;j!=0;j-=10)
                System.out.println("Chopping vegetables...("+j+" seconds left)");
        }   
     }
    class MixingThread extends Thread
    {
        public void run()
        {
            for(int k=60;k!=0;k-=10)
                System.out.println("Mixing sauces...("+k+" seconds left)");
        }
    }
    class TenderizingThread extends Thread
    {
        public void run()
        {
            for(int j=50;j!=0;j-=10)
                System.out.println("Tenderizing meat...("+j+" seconds left)");
        }
    }
    class MultiThreadTasking
    {
        public static void main (String [] args)
        {
            ChoppingThread ct = new ChoppingThread();
            MixingThread mt = new MixingThread();
            TenderizingThread tt = new TenderizingThread();
    
            System.out.println("\nWelcome to the busy kitchen.");
            //putting threads into ready state
            ct.start();
            mt.start();
            tt.start();
        }
    }
    

    To coordinate them use a CyclicBarrier.

    To launch them all at the same time use a CountDownLatch.

    Google the two classes above for many examples and explanations.

    To fully understand what is happening read the Java Concurrency In Practice book.

    for learning purpose i have tried to implements a queue data-structure + Consumer/producer chain that is thread-safe, for learning purpose too i have not used notify/wait mechanism :

    SyncQueue :

    package syncpc;
    
    /**
     * Created by Administrator on 01/07/2009.
     */
    public class SyncQueue {
    
       private int val = 0;
       private boolean set = false;
    
    
       boolean isSet() {
          return set;
       }
    
       synchronized  public void enqueue(int val) {
          this.val = val;
          set = true;
       }
    
       synchronized public int dequeue()  {
          set = false;
          return val;
       }
    }
    

    Consumer :

    package syncpc;
    
    /**
     * Created by Administrator on 01/07/2009.
     */
    public class Consumer implements Runnable {
        SyncQueue queue;
    
        public Consumer(SyncQueue queue, String name) {
            this.queue = queue;
    
            new Thread(this, name).start();
        }
    
    
        public void run() {
    
            while(true) {
                if(queue.isSet()) {
                    System.out.println(queue.dequeue());
                }
    
            }
        }
    }
    

    Producer :

    package syncpc;
    
    import java.util.Random;
    
    /**
     * Created by Administrator on 01/07/2009.
     */
    public class Producer implements Runnable {
        SyncQueue queue;
    
        public Producer(SyncQueue queue, String name) {
    
            this.queue = queue;
            new Thread(this, name).start();
        }
    
        public void run() {
            Random r = new Random();
    
            while(true) {
                if(!queue.isSet()) {
                        queue.enqueue(r.nextInt() % 100);
                }
            }
        }
    }
    

    Main :

    import syncpcwn.*;
    
    /**
     * Created by Administrator on 27/07/2015.
     */
    public class Program {
    
        public static void main(String[] args) {
            SyncQueue queue  = new SyncQueue();
    
            new Producer(queue, "PROCUDER");
            new Consumer(queue, "CONSUMER");
        }
    
    
    }
    

    The problem here, is that if isSet method is not synchronized , i got an ouput like that :

    97,
    55
    

    and the program just continue running without outputting any value. while if isSet method is synchronized the program work correctly.

    i don't understand why, there is no deadlock, isSet method just query the set instance variable without setting it, so there is no race condition.

    set needs to be volatile:

    private boolean volatile set = false;
    

    This ensures that all readers see the updated value when a write completes. Otherwise they will end up seeing the cached value. This is discussed in more detail in this article on concurrency, and also provides examples of different patterns that use volatile.

    Now the reason that your code works with synchronized is probably best explained with an example. synchronized methods can be written as follows (i.e., they are equivalent to the following representation):

    public class SyncQueue {
    
       private int val = 0;
       private boolean set = false;
    
    
       boolean isSet() {
          synchronized(this) {
              return set;
          }
       }
    
       public void enqueue(int val) {
          synchronized(this) {
              this.val = val;
              set = true;
          }
       }
    
       public int dequeue()  {
          synchronized(this) {
              set = false;
              return val;
          }
       }
    }
    

    Here, the instance is itself used as a lock. This means that only thread can hold that lock. What this means is that any thread will always get the updated value because only one thread could be writing the value, and a thread that wants to read set won't be able to execute isSet until the other thread releases the lock on this, at which point the value of set will have been updated.

    If you want to understand concurrency in Java properly you should really read Java: Concurrency In Practice (I think there's a free PDF floating around somewhere as well). I'm still going through this book because there are still many things that I do not understand or am wrong about.


    As matt forsythe commented, you will run into issues when you have multiple consumers. This is because they could both check isSet() and find that there is a value to dequeue, which means that they will both attempt to dequeue that same value. It comes down to the fact that what you really want is for the "check and dequeue if set" operation to be effectively atomic, but it is not so the way you have coded it. This is because the same thread that initially called isSet may not necessarily be the same thread that then calls dequeue. So the operation as a whole is not atomic which means that you would have to synchronize the entire operation.

    From Sun's tutorial:

    Synchronized methods enable a simple strategy for preventing thread interference and memory consistency errors: if an object is visible to more than one thread, all reads or writes to that object's variables are done through synchronized methods. (An important exception: final fields, which cannot be modified after the object is constructed, can be safely read through non-synchronized methods, once the object is constructed) This strategy is effective, but can present problems with liveness, as we'll see later in this lesson.

    Q1. Is the above statements mean that if an object of a class is going to be shared among multiple threads, then all instance methods of that class (except getters of final fields) should be made synchronized, since instance methods process instance variables?

    In order to understand concurrency in Java, I recommend the invaluable Java Concurrency in Practice.

    In response to your specific question, although synchronizing all methods is a quick-and-dirty way to accomplish thread safety, it does not scale well at all. Consider the much maligned Vector class. Every method is synchronized, and it works terribly, because iteration is still not thread safe.

    general question it can be in c i guess also
    if i have ( in my case http requst class ) that invoked from wrapper function
    this wrapper function is public API . then inside the wrapper function i init new Request object that suppose to do request with the parameters coming from the wrapper function
    do i need to wrap the request object in thread ( i have thread pool class that execute worker threads )
    does creating object on the stack for each request will do ?
    for example:

    public void Wrapper(String a,String b)
    {
    
    // im doing ..
    MyRequst req = new MyRequest(a,b); // will do the http requst 
    
    }
    
    or to do :
    
    public void Wrapper(String a,String b)
    {
    
    // im doing ..
    MyThreadPool.GetInstance().RunTask(new MyRequest(a,b)); // will do the http request 
    
    }
    

    The question isn't very clear, but from what can be inferred, the pertinent question is whether creating local variables is sufficient for thread-safety. The answer is yes.

    From Java Concurrency in Practice:

    Accessing shared, mutable data requires using synchronization;one way to avoid this requirement is to not share. If data is only accessed from a single thread, no synchronization is needed.

    It should be remembered that all objects are stored on the heap. The items on the stack are primitives and references to objects on the heap, and are termed as local variables and are always one-word wide (except for long and double values); these variables are not to be confused with the concept of method-local variables in the Java programming language (which people incorrectly assume to be stored on the stack).

    By using local variables, one ensures that the objects on the heap are accessible only to the current thread of execution, unless of course, any attempt was made to share such objects with other threads (in which case appropriate synchronization techniques needs to be employed).

    Here is my understanding about Java threads get scheduled when java launches a thread on invoke of start() api of java.lang.Thread class running on modern implementations of OS(like solaris 9).

    enter image description here Used the term LWP because term kernel thread is generally used in kernel programming to launch a thread.

    So, Every java thread creation using java.lang.Thread::start() api has 1:1 map with native thread creation using pthread_create() or thr_create() or CreateThread() on POSIX, Solaris, Windows platforms respectively. In-turn, each native thread has 1:1 map with an LWP.

    My question:

    1)

    Can i say, there is no Java thread scheduling policy in user space jvm to schedule java threads anymore based on 1-1 threading model in the above diagram?

    2) Supplementary: In dual core processor scenario, Does those 2 LWP's(representing an each JVM process) have equal chance to execute simultaneously(parallel)?

    Note: As a java beginner, i need this clarity

    The diagram details the inner workings of the jvm, and how it abstracts from the lower level operating system threads to the java thread model. This is how the JVM runs on the above operating systems.

    To answer your questions directly:

    1. ) Everytime you create a thread, you create a thread for the operating system to manage. The JVM has a layer of abstraction between you and the operating system, so that you can work with the same thread model on different systems. In general, for unoptimized java code, a java thread is an OS thread.

    2. ) You don't have any guarantees on executing in parallel. Depending on the CPU load, the operating system may need the resources else where for higher priority systems. When writing multithreaded applications, write as though whatever is going on outside the thread is unknown.

    If you want to know more about the java multithreaded model, I recommend this book. This book is old, but it is still relevant. It was written by the Java language architect, and it goes into details about the Java multithreading model

    I am confused if we should make our own threads in servlet or not,as they have threading mechanism internally?. If yes how can we make sure if the program thread safe? How to implement thread safe mechanism in servlets.

    You are asking two different questions:

    I am confused if we should make our own threads in servlet or not,as they have threading mechanism internally?.

    Normally, you should not start threads in a Java EE application. If you need seperate threads, make sure you use a Scheduler Service that your application knows about, so that it has the chance to shut down the threads when the application is shut down. Quartz is what's used most of the time.

    If yes how can we make sure if the program thread safe? How to implement thread safe mechanism in servlets.

    Servlets are just like any other Java class. Find a tutorial on thread safety or read Java Concurrency in Practice.

    I am reading the book Java concurrency in practice, in section 3.2 , it gives the following code example to illustrate implicitly allowing the this reference to escape (Don’t do this, especailly in constructor) :

    public class ThisEscape {
        public ThisEscape(EventSource source) {
           source.registerListener ( 
                 new EventListener() {
                     public void onEvent(Event e) {
                         doSomething(e);
                     }
                 }
           );
      } 
    }
    

    The book then says :

    When ThisEscape publishes the EventListener, it implicitly publishes the enclosing ThisEscape instance as well, because inner class instances contain a hidden reference to the enclosing instance.

    I understand the above words from Java's perspective, but I can't come up with a example how could the above code's EventListener escaping enclosing reference this be harmful? In what way?

    For example, if I create a new instance of ThisEscape:

    ThisEscape myEscape = new Escape(mySource);
    

    Then, what? How is it harmful now? In which way it is harmful?

    Could someone please use above code as the base and explain to me how it is harmful?

    ======= MORE ======

    The book is trying to say something like the anonymous EventListener holds a hidden reference to the containing class instance which is not yet fully constructed. I want to know in example, how could this un-fully constructed reference be misused, and I prefer to see a code example about this point.

    The book gives a right way of doing things, that's to use a static factory method as below:

    public static SafeListener newInstance(EventSource source) { 
           SafeListener safe = new SafeListener(); 
           source.registerListener (safe.listener);
           return safe;
    }
    

    I just don't get the point of the whole thing.

    Problem 1: Operating on non-fully-constructed object

    Consider this slightly modified example:

    public class ThisEscape {
        private String prefixText = null;
    
        private void doSomething(Event e) {
            System.out.println(prefixText.toUpperCase() + e.toString());
        }
    
        public ThisEscape(EventSource source) {
           source.registerListener( 
                 new EventListener() {
                     public void onEvent(Event e) {
                         doSomething(e); // hidden reference to `ThisEscape` is used
                     }
                 }
           );
    
           // What if an event is fired at this point from another thread? 
           // prefixText is not yet assigned, 
           // and doSomething() relies on it being not-null
    
           prefixText = "Received event: ";
        }
    }
    

    This would introduce a subtle and very hard-to-find bug, for example in multithreaded applications.

    Consider that the event source fires and event after source.registerListener(...) has completed, but before prefixText was assigned. This could happen in a different thread.

    In this case, the doSomething() would access the non-yet-initialized prefixText field, which would result in a NullPointerException. In other scenarios, the result could be invalid behavior or wrong calculation results, which would be event worse than an exception. And this kind of error is extremely hard to find in real-world applications, mostly due to the fact that it happens sporadically.

    Problem 2: Garbage collection

    The hidden reference to the enclosing instance would hinder the garbage collector from cleaning up the "enclosing instance" in certain cases.

    This would happen if the enclosing instance isn't needed anymore by the program logic, but the instance of the inner class it produced is still needed.

    If the "enclosing instance" in turn holds references to a lot of other objects which aren't needed by the program logic, then it would result in a massive memory leak.


    A code example. Given a slightly modified ThisEscape class form the question:

    public class ThisEscape {
    
        private long[] aVeryBigArray = new long[4711 * 815];
    
        public ThisEscape(EventSource source) {
           source.registerListener( 
                 new EventListener() {
                     public void onEvent(Event e) {
                         doSomething(e);
                     }
                     private void doSomething(Event e) {
                         System.out.println(e.toString());
                     }
                 }
           );
        } 
    }
    

    Please note that the inner anonymous class (which extends/implements EventListener) is non-static and thus contains a hidden reference to the instance of the containing class (ThisEscape).

    Also note that the anonymous class doesn't actually use this hidden reference: no non-static methods or fields from the containing class are used from within the anonymous class.

    Now this could be a possible usage:

    // Register an event listener to print the event to System.out
    new ThisEscape(myEventSource); 
    

    With this code we wanted to achieve that an event is registered within myEventSource. We do not need the instance of ThisEscape anymore.

    But assuming that the EventSource.registerListener(EventListener) method stores a reference to the event listener created within ThisEscape, and the anonymous event listener holds a hidden reference to the containing class instance, the instance of ThisEscape can't be garbage-collected.

    I've intentionally put a big non-static long array into ThisEscape, to demonstrate that the ThisEscape class instance could actually hold a lot of data (directly or indirectly), so the memory leak can be significant.

    I am working on an application, that processes incoming messages. I am not proficient in java multithreading and I am asking your help, folks. Is there anything wrong with the following app structure.

    There is main application class with stopRequested boolean field. And there is internal runnable class that listens for incoming messages and process them. Also there is another thread that sets stopRequested to true.

    Is this approach working and reliable, or I am wrong?

    Below there is a part of my code:

    class ApplicationClass {
    
        // we set this var in another thread
        // when it is necessary to stop
        private stopRequested = false;
    
    
        public ApplicationClass() {
    
            // starting message processing thread
            (new Thread(new MessageProcessing())).start();
    
        }
    
    
        private class MessageProcessing implements Runnable {
    
    
            public void run() {
    
                while (!stopRequested) {
    
                    if (getNewMessagesCount() > 0) {
    
                        processNewMessages();
    
                    }
    
                }
    
            }
        }       
    } 
    

    Thank you.

    There are a few things to think about.

    1. As sbridges noted stopRequested needs to be volatile to resolve visibility problems (a thread on another core may not see the change otherwise).
    2. If getNewMessagesCount() doesn't block then your while loop will spin and consume the core; this will give you the lowest latency but ties up the entire core.
    3. The code you've listed appears to be a simple processing queue; you're likely going to be better off going with an ArrayBlockingQueue.
    4. It's dangerous to start a new thread from a constructor. The thing to worry about is what happens if getMessageCount() and processNewMessages() are invoked before ApplicationClass is finished being created. Since the instance of ApplicationClass could be in an incomplete state you could find a rather nasty bug. (For the same reason you never want to have your code subscribe as a listener to events from a constructor, by the way.) Check out Effective Java for more background on this topic.
    5. Your while loop should check if the current thread has been interrupted so that it places nice; it should be while (!stopRequested && !Thread.currentThread().isInterrupted())

    Writing correct concurrent programs is hard. I highly recommend reading Java Concurrency in Practice; it will save you a lot of pain.

    I don't like to lock up my code with synchronized(this), so I'm experimenting with using AtomicBooleans. In the code snippet, XMPPConnectionIF.connect() makes a socket connection to a remote server. Note that the variable _connecting is only ever used in the connect() method; whereas _connected is used in every other methods that needs to use the _xmppConn. My questions are listed after the code snippet below.

    private final AtomicBoolean _connecting = new AtomicBoolean( false );
    private final AtomicBoolean _connected = new AtomicBoolean( false ); 
    private final AtomicBoolean _shuttingDown = new AtomicBoolean( false ); 
    private XMPPConnection _xmppConn;
    /**
     * @throws XMPPFault if failed to connect
     */
    public void connect() 
    {
        // 1) you can only connect once
        if( _connected.get() )
            return;
    
        // 2) if we're in the middle of completing a connection, 
        //    you're out of luck
        if( _connecting.compareAndSet( false, true ) )
        {
            XMPPConnectionIF aXmppConnection = _xmppConnProvider.get();
            boolean encounteredFault = false;
    
            try
            {
                aXmppConnection.connect(); // may throw XMPPException
                aXmppConnection.login( "user", "password" ); // may throw XMPPException
                _connected.compareAndSet( false, true );
                _xmppConn = aXmppConnection;
            }
            catch( XMPPException xmppe )
            {
                encounteredFault = true;
                throw new XMPPFault( "failed due to", xmppe );
            }
            finally
            {
                if( encounteredFault )
                {
                    _connected.set( false );
                    _connecting.set( false );
                }
                else
                    _connecting.compareAndSet( true, false );
            }
        }
    }
    
    1. Based on my code, is it thread safe to the point that if 2 threads attempt to call connect() at the same time, only one connection attempt is allowed.

    2. In the finally block, I am executing two AtomicBoolean.set(..) in succession, will be there be a problem, since during the gap between these 2 atomic calls, some threads might call _connected.get() in other methods ?

    3. When using _xmppConn, should I do a synchronized( _xmppConn ) ?

    UPDATE Added missing login call into the method.

    Keep in mind that using 3 AtomicBooleans is not the same as guarding those three variables with a single lock. It seems to me like the state of those variables constitutes a single state of the object and thus that they should be guarded by the same lock. In your code using atomic variables, it's possible for different threads to update the state of _connected, _connecting, and _shuttingDown independently -- using atomic variables will only ensure that access to the same variable is synchronized between multiple threads.

    That said, I don't think synchronizing on the this is what you want to do. You only want to synchronize access to the connection state. What you could do is create an object to use as the lock for this state without getting the monitor on this. Viz:

    class Thing {
      Boolean connected;
      Boolean connecting;
      Boolean shuttingDown;
      Object connectionStateLock = new Object();
    
      void connect() {
        synchronized (connectionStateLock) {
          // do something with the connection state.
        }
      }
    
      void someOtherMethodThatLeavesConnectionStateAlone() {
        // free range thing-doing, without getting a lock on anything.
      }
    }
    

    If you're doing concurrent programming in Java, I would highly recommend reading Java Concurrency In Practice.

    I have a general doubt regarding publishing data and data changes across threads. Consider for example the following class.

    public class DataRace {
      static int a = 0;
    
      public static void main() {
        new MyThread().start();
        a = 1;
      }
    
      public static class MyThread extends Thread {
        public void run() { 
          // Access a, b.
        }
      }
    }
    

    Lets focus on main().

    Clearly

    new MyThread().start();
    a = 1;
    

    There we change the shared variable a after the MyThread is started and thus may not be a thread-safe publication.

    a = 1;
    new MyThread().start();
    

    However this time the change in a is safely published across the new thread, since Java Language Specification (JLS) guarantees that all variables that were visible to a thread A when it starts a thread B are visible to thread B, which is effectively like having an implicit synchronization in Thread.start().

    new MyThread().start();
    int b = 1;
    

    In this case when a new variable is allocated after both the threads have been spawned, is there any guarantee that that the new variable will be safely published to all threads. i.e. if var b is accessed by the other thread, is it guaranteed to see its value as 1. Note that I'm not talking about any subsequent modifications to b after this (which certainly needs to be synchronized), but the first allocation done by the jvm.

    Thanks,

    I'm not sure what you're asking here. I think you're talking about thread-safe access to the "a" variable.

    The issue is not the order of invocation but the fact that

    -access to a is not threadsafe. So in an example with multiple threads updating and reading a, you won't ever be able to guarantee that the "a" you're reading is the same value as what you updated from (some other thread may have changed the value).

    -in a multithreaded environment the jvm does not guarantee that the updated values for a are kept in sync. E.g.

    Thread 1: a=1
    
    Thread 2: a=2
    
    Thread 1: print a <- may return 1
    

    You can avoid this by declaring a "volatile".

    As written there are no guarantees at all about the value of a.

    BTW, Josh Bloch's Concurrency in Practice is a great book on this subject ( and I say that not having gotten all the way through it yet ;) - it really helped me to understand just how involved threading issues can get.

    I have a piece of code that looks like this:

    Algorithm a = null;  
    while(a == null)  
    {  
        a = grid.getAlgorithm();  
    }  
    

    getAlgorithm() in my Grid class returns some subtype of Algorithm depending on what the user chooses from some options.

    My problem is that even after an algorithm is selected, the loop never terminates. However, that's not the tricky bit, if I simply place a System.out.println("Got here"); after my call to getAlgorithm(), the program runs perfectly fine and the loop terminates as intended.

    My question is: why does adding that magic print statement suddenly make the loop terminate?

    Moreover, this issue first came up when I started using my new laptop, I doubt that's related, but I figured it would be worth mentioning.

    Edit: The program in question is NOT multithreaded. The code for getAlgorithm() is:

    public Algorithm getAlgorithm ()  
    {  
        return algorithm;  
    }
    

    Where algorithm is initially null, but will change value upon some user input.

    There are two scenarios:

    1. Your code is really not meant to be multi-threaded. In this case you need to insert some sort of user input in the loop. Otherwise you might as well leave it as Algorithm a = grid.getAlgorithm(); and prevent the infinite loop.
    2. Your code is multi-threaded in which case you have some sort of 'visibility' problem. Go to Atomicity, Visibility and Ordering or read Java Concurrency in Practice to learn more about visibility. Essentially it means that without some sort of synchronization between threads, the thread you are looping in may never find out that the value has changed due to optimizations the JVM may perform.

    You did not mention any context around how this code is run. If it is a console based application and you started from a 'main' function, you would know if there was multi-threading. I am assuming this is not the case since you say there is no multithreading. Another option would be that this is a swing application in which case you should read Multithreaded Swing Applications. It might be a web application in which case a similar case to swing might apply.

    In any case you could always debug the application to see which thread is writing to the 'algorithm' variable, then see which thread is reading from it.

    I hope this is helpful. In any case, you may find more help if you give a little more context in your question. Especially for a question with such an intriguing title as 'Weird Java problem, while loop termination'.

    I have a relatively large amount of code written without threads in mind. I am new at Java, and programming in general, so I am having a little trouble figuring out how to run the program I have built in threads without going back into all my classes and changing them to have a run() method. I can't even imagine how that's possible where I have multiple methods that are meant to be called separately from other classes.

    I can't seem to find a way to create a thread for (every/a) new call to the code from the GUI. Say I have a method for inserting data into a database. The method is named and written. I could put a call to that class and method into my main, but what then when I want to call some other method? I have 25+ methods at least, and I can't really see my main class just being overloaded 25 times as "Best practice." Is there a way to create a thread and give it an object to handle dynamically, so to say?

    In short: I want to use threads in my program without overloading my main, how do I do so?

    Honestly, there is no universal way of converting singlethreaded application to multithreaded because it requires different design depending on your goal. And "multithreaded application" is not really a goal :)

    You didn't specify how you built your UI. But if you use Swing and want to do some lengthy task without freezing your user interface use SwingWorker

    On the general note I'd recommend reading book "Java Concurrency in Practice". It's pretty good.

    I'm building a GUI'd application with javaFX that supports a long-running CPU intensive operation, something like Prime95 or Orthos.

    One of the problems I've run into is trying to get counters to increment nicely. If you think about an ElapsedTime field with an incrementing counter with millisecond resolution, what I need is a job on the UI thread to call elapsedTimeTextField.setText("00:00:00.001") to happen 1ms before a corresponding call elapsedTimeTextField.setText("00:00:00.002"). I also need to let the UI thread do more important jobs between those two calls.

    Structuring code to do this has been tedious, and has resulted in a number of our controller classes creating threads that simply loop on code similar to:

    Thread worker = new Thread(this::doUpdates);
    worker.start();
    
    //...
    
    private void doUpdates(){
      while(true){
        String computedTime = computeTimeToDisplay();
        runLaterOnUI(() -> textField.setText(computedTime));
        sleep(DUTY_CYCLE_DOWNTIME);
      }
    }
    

    While this does the job, its unfavorable because:

    • It's difficult to unit test: from a testing environment you either have to modify this code to give some kind of signal when it completes its first pass, (typically a count-down-latch) or you have to do silly non-deterministic & arbitrary sleep()s
    • It doesn't have any kind of backoff: if the UI thread is flooded with jobs this code is going to exacerbate the problem. Some kind of requeueing scheme, whereby the downtime takes into account the latency of the job and some kind of hard-coded sleep is preferable since it means that if the UI job is flooded we're not asking it to do work unduly.
    • It doesn't have centralized exception handling short of the threads default handler. This means that if an exception is raised in the computeTimeToDisplay() method (or for that fact, in the runLaterOnUI call or the sleep() call) the text field will no longer be updated.

    I have addressed each of these concerns reasonably well individually, but I don't have any obvious and reusable idiom for tackling these three problems.

    I suspect that the Future, Task, Executor, ServiceExecutor, etc classes (the classes in the java.util.concurrent package that aren't a lock or a collection) can help me to this goal, but I'm not sure how to use them.

    Can somebody suggest some documentation to read and some idioms to follow that will help me in pursuit of these goals? Is there an agreed on idiom --that doesn't involve anonymous classes and contains minimal boiler-plate-- for this kind of concurrent-job?

    You question is multi-faceted and I am not going to pretend that I understand all of it. This answer will address only one part of the question.

    It doesn't have any kind of backoff: if the UI thread is flooded with jobs this code is going to exacerbate the problem. Some kind of requeueing scheme, whereby the downtime takes into account the latency of the job and some kind of hard-coded sleep is preferable since it means that if the UI job is flooded we're not asking it to do work unduly.

    The in-built java.util.concurrent classes such as Task, Service and ScheduledService include facilities to send message updates from a non-UI thread to a UI thread in way that does not flood the UI thread. You could use those classes directly (which would seem advisable, though perhaps that perception is naive of me as I don't fully understand your requirements). Or you can implement a similar custom facility in your code if you aren't using java.util.concurrent directly.

    Here is the relevant code from the Task implementation:

    /**
     * Used to send message updates in a thread-safe manner from the subclass
     * to the FX application thread. AtomicReference is used so as to coalesce
     * updates such that we don't flood the event queue.
     */
    private AtomicReference<String> messageUpdate = new AtomicReference<>();
    
    private final StringProperty message = new SimpleStringProperty(this, "message", "");
    
    /**
     * Updates the <code>message</code> property. Calls to updateMessage
     * are coalesced and run later on the FX application thread, so calls
     * to updateMessage, even from the FX Application thread, may not
     * necessarily result in immediate updates to this property, and
     * intermediate message values may be coalesced to save on event
     * notifications.
     * <p>
     *     <em>This method is safe to be called from any thread.</em>
     * </p>
     *
     * @param message the new message
     */
    protected void updateMessage(String message) {
        if (isFxApplicationThread()) {
            this.message.set(message);
        } else {
            // As with the workDone, it might be that the background thread
            // will update this message quite frequently, and we need
            // to throttle the updates so as not to completely clobber
            // the event dispatching system.
            if (messageUpdate.getAndSet(message) == null) {
                runLater(new Runnable() {
                    @Override public void run() {
                        final String message = messageUpdate.getAndSet(null);
                        Task.this.message.set(message);
                    }
                });
            }
        }
    }
    

    The code works by ensuring that a runLater call is only made if the UI has processed (i.e. rendered) the last update.

    Internally the JavaFX 8 system runs on a pulse system. Unless there is an unusually long time consuming operation on the UI thread or general system slowdown, each pulse will usually occur 60 times a second, or approximately every 16-17 milliseconds.

    You mention the following:

    what I need is a job on the UI thread to call elapsedTimeTextField.setText("00:00:00.001") to happen 1ms before a corresponding call elapsedTimeTextField.setText("00:00:00.002").

    However, you can see from the JavaFX architecture description that updating the text more than 60 times a second is pointless as the additional updates will never be rendered. The sample code above from Task, takes care of this by ensuring that a UI update request is only ever issued at a time that the UI update thread can actually reflect the new value in the UI.

    Some General Advice

    This is just advice, it does not directly solve your problem, take it for what you will, some of it might not even be particularly relevant to your situation or problem.

    1. Make clear the problem you are trying to solve in your questions. That is sometimes more important than a description of the symptoms you are experiencing and trying to resolve. It also helps prevent XY questions.
    2. Be clear from the start on what you are actually doing to solve the problem. An mcve can sometimes help here.
    3. For example, your initial problem statement does not state that you may have 10,000 controllers or provide code for what you term to be a controller. There is not much information on the expected length of time for tasks, what the UI display representing task progress and result is, why millisecond accuracy level might be important to display, if task results need to coalesced, if the tasks can be split and run concurrently, how many threads you are using, etc.
    4. Don't try to develop your own higher level concurrency tools from primitives like ConcurrentLinkedQueue.
    5. For your backend segmented work jobs, use high level concurrency utilities from Java SE, such as Executors, ForkJoin and BlockingQueue.
    6. Orchestrate and synchronize the output of backend jobs with your UI using JavaFX concurrency utilities such as Task.
    7. Know that the high level concurrency utilities and JavaFX concurrency tools can be used in unison, like in this example. I.e., the choice of concurrency tools doesn't need to be an either/or situation.
    8. Extensive use of immutable objects can be a lifesaver in concurrent development.
    9. If you will be doing a lot of concurrent development, take time for detailed study of high quality resources on concurrent programming such as Concurrency in Practice.
    10. Concurrency in general is often simply hard to get right.

    I'm wondering what the difference is between these ways of synchronization

    List<Integer> intList = Collections.synchronizedList(new ArrayList<Integer>());
    
    synchronized (intList) {
        //Stuff
    }
    

    and using an object lock

    Object objectLock = new Object();
    
    List<Integer> intList = new ArrayList<Integer>();
    
    synchronized (objectLock) {
        //Stuff
    }
    

    The code you show is not necessarily thread safe yet!!

    The only difference between one excerpt and the other is the object you use as a monitor for synchronization. This difference will determine which object should be used for synchronization by other threads that need access to the mutable data you're trying to protect

    great read for this: java concurrency in practice

    I've been having this memory leak issue for days and I think I have some clues now. The memory of my java process keeps growing but yet the heap does not increase. I was told that this is possible if I create many threads, because Java threads uses memory outside of the heap.

    My java process is a server type program so there are 1000-2000 threads. Created and deleted ongoing. How do I reclaim the memory used by a java thread? Do I simply erase all references to the thread object and make sure that this is terminated?

    From the Java API docs threads die when:

    All threads that are not daemon threads have died, either by returning from the call to the run method or by throwing an exception that propagates beyond the run method.

    Threads die when they return from their run() method. When they die they are candidates for garbage collection. You should make sure that your threads release all references to objects and exit the run() method.

    I don't think that nulling references to your threads will really do the trick.

    You should also check out the new threading facilities in Java 5 and up. Check the package java.util.concurrent in the API documentation here.

    I also recommend you to check the book Concurrency in Practice. It's being priceless for me.

    I've inherited some code that uses Executors.newFixedThreadPool(4); to run the 4 long-lived threads that do all the work of the application.

    Is this recommended? I've read the Java Concurrency in Practice book and there does not seem to be much guidance around how to manage long-lived application threads.

    What is the recommended way to start and manage several threads that each live for the entire live of the application?

    I want to master concurrent programming.
    I heard that there are good books for concurrent programming in java by Doug Lea

    Which book should I read first ? Are there other books. If anyone can tell me also guide me how practice this topic.

    Java Concurrency in Practice is the more recent of the two, so I recommend that. It covers lots of stuff, including the new concurrency utilities, which the other doesn't. However, CPiJ also contains stuff which is still relevant and is not repeated in JCiP, so you may want to check that out later too.

    Usually I use the first implementation. Couple of days ago I found another. Can anyone explain me the difference between these 2 implementations ? The 2nd implementation is thread safe? What is the advantage of using inner class in the 2nd example?

    //--1st Impl
    public class Singleton{
    
          private static Singleton _INSTANCE;
    
          private Singleton() {}
          public static Singleton getInstance(){
              if(_INSTANCE == null){
                   synchronized(Singleton.class){
                          if(_INSTANCE == null){
                              _INSTANCE = new Singleton();
                          }
                   }
              }
          return _INSTANCE;
          }  
    }
    
    //--2nd Impl
    public class Singleton {
          private Singleton() {}
    
          private static class SingletonHolder { 
                private static final Singleton _INSTANCE = new Singleton();
          }
    
          public static Singleton getInstance() {
                return SingletonHolder._INSTANCE;
          }
    }
    

    The first implementation uses what is called a "double checked lock". This is a Very Bad Thing. It looks thread-safe, but in fact it is not.

    The second implementation is, indeed, thread-safe.

    The explanation for why the first implementation is broken is fairly involved, so I'd recommend you get a copy of Brian Goetz's Java Concurrency in Practice for a detailed explanation. The short version is that the compiler is allowed to assign the _INSTANCE variable before the constructor has completed, which can cause a second thread to see a partially-constructed object.

    The Java Tutorials listed a couple of books for further reading regarding threading / concurrency:

    1. Concurrent Programming in Java: Design Principles and Pattern

    2. Java Concurrency in Practice

    3. Concurrency: State Models & Java Programs

    (Since going through a book could take a hundred hours,) Out of these three books, which would be the most comprehensive one?

    i propose you something slightly different: Programming Concurrency on the JVM.

    This will explain to you the different models and the different problems with concurrency on the JVM. Not entirely targeted at Java, but at the JVM ecosystem, it will give you a deep understanding, along with the technical tools.

    Can the synchronization statements be reordered. i.e : Can :

    synchronized(A) {
       synchronized(B) {
         ......
       }
    }
    

    become :

    synchronized(B) { 
        synchronized(A) { 
         ...... 
         }  
    }
    

    Yes and no.

    The order must be consistent.

    Suppose you are creating a transaction between two bank accounts, and always grab the sender's lock first, then grab the receiver's lock. Problem is - say both Dan and Bob want to transfer money to each other at the same time.

    Thread 1 might grab Dan's lock, as it processes Dan's transaction to Bob.
    Then thread 2 grab's Bob's lock, as it processes Bob's transaction to Dan.

    Then, bam, deadlock.

    The morals are:

    1. Lock less.
    2. Read Java: Concurrency in Practice. My example is taken from there. I like arguing about the merits of books in programming as much as the next guy, but it's pretty rare you get comprehensive coverage of a difficult topic between two covers, so enjoy it.

    So this is the part of the answer where I guess at other things you might have been trying to ask instead, because the expectation is firmly on me that I act psychic.

    The JVM will not acquire the locks in an order different from which you have programmed. How do I know this? Because otherwise it would not be possible to solve the problem in the first half of my answer.

    public void execute(Runnable command)

    This command object contains the submitted object, but it seems to have been wrapped.

    How can I access the submitted object from within a custom thread pool executor? Or is it not such a good idea to try and access the submitted object from inside a ThreadPoolExecutor's before/after/execute methods?

    Don't use execute, use submit, which returns a Future, which is a handle to the task. Here's some example code:

    ExecutorService service = Executors.newCachedThreadPool();
    
    Callable<String> task = new Callable<String>() {
        public String call() throws Exception {
            return "hello world";
        }
    };
    
    Future<String> future = service.submit(task);
    

    Although you can't access the task directly, you can still interact with it:

    future.cancel(); // Won't start task if not already started
    String result = future.get(); // blocks until thread has finished calling task.call() and returns result
    future.isDone(); // true if complete
    

    You can also interact with the service:

    service.shutdown(); //etc    
    

    EDITED TO INCORPORATE COMMENTS:

    If you want to do some logging, use an anonymous class to override the afterExecute() method, like this:

        ThreadPoolExecutor executor = new ThreadPoolExecutor(1, 1, 1, TimeUnit.SECONDS, new ArrayBlockingQueue<Runnable>(1)) {
            @Override
            protected void afterExecute(Runnable r, Throwable t)
            {
                // Do some logging here
                super.afterExecute(r, t);
            }
        };
    

    Override other methods as required.

    Quick plug: IMHO, the bible for this subject is Java Concurrency in Practice - I recommend you buy it and read it.

    How can I make use of parallel in Java? Or do I use normal threads?

    What a big topic! A typical solution is using multi-threading, you need a class implemented Runnable interface and put your function into its run() method. For details, I suggest you buy a copy of Java Concurrency in Practice.

    I am implementing a game and I want to ask the player to click on a specific view.

    I want my control thread to wait until I get a value back (I have clicked on the view and handled the result). Currently I am doing this by creating a thread, running a method that asks them to click and then entering a while loop that is terminated when the mouse click event changes a variable used in the while loop.

    I am writing a game where I have a thread constantly receiving events. On a specific event, I want to prompt the user for a response, but to do this would require me to be on the JavaFX thread (to my knowledge).

    Is there a better way of doing this in JavaFX? Thanks!

    There are several tools "hidden" in the JDK documentation on threads that can help you resolve this type of issue. Usually when we make a routine code wait for some condition that can proceed we use threads synchronizers.

    I want my control thread to wait until I get a value back [...]

    CountDownLatch, CyclicBarrier and FutureTask may be classes that can solve your problem. The functionality of these is quite simple. They have the function of stopping threads and release them when some condition is met. The difference in each of these classes is just semantics applied for termination and release threads. Read the documentation of each and see which one is most comfortable to you.

    You can also take a look at other sources of study. There is no better source of study in the world (in my opinion) than the content within the book "Java Concurrency In Practice" by Brian Goetz. I assure you that you will become able to easily manipulate threads if you buy this book (or at least gain an incredible knowledge on the subject). Make it clear that you do not need to buy the book to solve your current problem. Buying the book is just my suggestion for you to have more knowledge about threads. You probably will solve your problem by looking at the documentation of classes that synchronize threads I mentioned.

    Good luck in your projects. ;)

    I am learning java concepts...i just want to understand the synchronization with multi threading concept once. When we are using multi threading, we generally go for synchronization in order to align the transactions in sync.

    But by adding this u end up with more utilisation of time. How to make application in sync and to use multi threading as well...are their any concepts in java which solve this...

    You're thinking of Amdahl's law, which implies that from a big-O standpoint, yes, synchronized sections completely defeat the point of multithreading.

    The point is to keep synchronized sections as small as possible so they don't become bottlenecks at the scale you're actually anticipating. Or to use other concurrency patterns that simulate synchronization but do not require a lock. Read Java: Concurrency in Practice.

    I am learning Java concurrency and know that the following singleton is not completely thread safe. A thread may get instance before it is initialized because of instructions reordering. A correct way to prevent this potential problem is to use volatile keyword.

    public class DoubleCheckedLocking {
        private static Instance instance;
        public static Instance getInstance() {
            if (instance == null) {
                synchronized (DoubleCheckedLocking.class) {
                    if (instance == null)
                        instance = new Instance();
                }
            }
            return instance;
        }
    }
    

    I tried to reproduce the potential problem without volatile keyword and wrote a demo to show that using the above code may cause a NullPointerException in multithreading environment. But I failed to find a way to explicitly let the Java compiler perform instructions reordering and my demo with the above singleton always works pretty well without any problems.

    So my question is how to explicitly enable/disable Java compiler to reorder instructions or how to reproduce the problem without using volatile keyword in a double-checked locking singleton?

    This is an excerpt from the Java Concurrency in Practice book:

    Debugging tip: For server applications, be sure to always specify the -server JVM command line switch when invoking the JVM, even for development and testing. The server JVM performs more optimization than the client JVM, such as hoisting variables out of a loop that are not modified in the loop; code that might appear to work in the development environment (client JVM) can break in the deployment environment (server JVM). For example, had we "forgotten" to declare the variable asleep as volatile in Listing 3.4, the server JVM could hoist the test out of the loop (turning it into an infinite loop), but the client JVM would not. An infinite loop that shows up in development is far less costly than one that only shows up in production.

    So you can give it a try. But there is no 100% sure way of enabling reordering.

    I am trying to understand Java multi-threading constructs, and I am trying to write a simple implementation of blocking queue. Here is the code I have written:

      class BlockingBoundedQueue<E>
        {
            @SuppressWarnings("unchecked")
            BlockingBoundedQueue(int size)
            {
                fSize = size;
                fArray = (E[]) new Object[size];
    //            fBlockingQueue = new ArrayBlockingQueue<E>(size);
            }
    
            BlockingQueue<E> fBlockingQueue;
    
            public synchronized void put(E elem)
            {
                if(fCnt==fSize-1)
                {
                    try
                    {
                        // Should I be waiting/locking on the shared array instead ? how ?
                        wait();
                    }
                    catch (InterruptedException e)
                    {
                        throw new RuntimeException("Waiting thread was interrupted during put with msg:",e);
                    }
                }
                else
                {
                    fArray[fCnt++]=elem;
                    //How to notify threads waiting during take()
                }
            }
    
    
            public synchronized E take()
            {
                if(fCnt==0)
                {
                    try
                    {
                        // Should I be waiting/locking on the shared array instead ? how ?
                        wait();
                    }
                    catch (InterruptedException e)
                    {
                        throw new RuntimeException("Waiting thread was interrupted during take with msg:",e);
                    }
                }
    
                return fArray[fCnt--];
                //How to notify threads waiting during put()
            }
            private int fCnt;
            private int fSize;
            private E[] fArray; 
    
        }
    

    I want to notify threads waiting in Take() from put() and vice versa. Can someone please help me with the correct way of doing this.

    I checked the java.utils implementation and it uses Condition and ReentrantLocks which are a little complex for me at this stage. I am okay of not being completely robust[but correct] for the sake of simplicity for now.

    Thanks !

    The short answer is, call notifyAll() where you have the comments //How to notify threads waiting during take()

    Now for the more complete answer...

    The reference to read is : Java Concurrency in Practice. The answer to your question is in there.

    However, to briefly answer your question: in Java, threads synchronize by locking on the same object and using wait() and notify() to safely change state. The typical simplified flow is:

    1. Thread A obtains a lock by entering a synchronized block on a lock object
    2. Thread A checks some condition in a loop, if not "OK to go" call thread.wait(), which is a blocking call that "releases" the lock so other code synchronized on the same lock object can proceed
    3. Thread B obtains the same lock and may do something that changes the condition thread A is waiting for. When it calls notifyAll(), thread A will wake up and recheck the condition and (may) proceed

    Some things to remember about synchronization are:

    • it is about keeping state of objects consistent by making changes to state atomic. "Atomic" means the entire change (e.g. to multiple fields) is guaranteed to complete (no partial, and therefore inconsistent, changes)
    • it is cooperative - code synchronized on a given lock object has in common the state that is being changed and the conditions that allow that state change - you wait and notify about the same "subject". Each part of state should be guarded by its own lock object - usually a private field, e.g. private Object lock = new Object(); would be fine
    • methods that are synchronized use this as the lock object - doing this is easy but potentially expensive, because you are locking for every call, instead of just when you need to
    • static methods that are synchronized use the Class object as the lock object

    I created a FutureTask in an analog way to what is presented in Brian Goetz's book Java Concurrency in Practice (the code sample can be found here, listing 5.12).

    The problem is that the task times out even if given 10 seconds. The task just returns true so there shouldn't be a reason for it to happen:

    public static void main(String[] args) throws Exception {
    
        FutureTask<Boolean> task = new FutureTask<>(new Callable<Boolean>() {
            @Override
            public Boolean call() throws Exception {
                return true;
            }
        });
    
        System.out.println(task.get(10, TimeUnit.SECONDS));
    }
    

    This code prints:

    Exception in thread "main" java.util.concurrent.TimeoutException
        at java.util.concurrent.FutureTask.get(Unknown Source)
        at Main.main(Main.java:19)
    

    You haven't executed the task. There will never be a result available. The javadoc states

    This class provides a base implementation of Future, with methods to start and cancel a computation, query to see if the computation is complete, and retrieve the result of the computation. The result can only be retrieved when the computation has completed

    Submit the task to an ExecutorService to be run asynchronously.

    Executors.newSingleThreadExecutor().submit(task); // ideally shutdown the ExecutorService afterwards
    

    or run it synchronously

    task.run();
    

    In the links you've given, I'm assuming the start() method which runs the FutureTask in a new Thread is called before attempting to get the result.

    I don't know whether this question will be closed or not, though I hope no as I ask this quite seriously.

    I want to learn details of Java Threading, maybe a little bit low level of how exactly Java controls threads. The purpose of this is majorly to conquer my future job hunting path.

    I have Googled it and I found it seems many people chose these two books

    1. Concurrent Programming in Java™: Design Principles and Pattern (2nd Edition)

    2. Java Concurrency in Practice

    The 1st one (Concurrent Programming in Java™) is also recommended by the famous Googler Steve Yegge in his post Get that job at Google

    But I found it quite old (published in 1999) and in the reviews at Amazon, also some people say it is too old.

    The 2nd one is also recommended by many others.

    I don't know how to choose. Could anyone give me some good advices?

    P.S. I know a good advice would be "Just Buy both and read both", but I may not be able to take this advice because my budget is not that much and more importantly I don't have that much time to finish studying both. I have to choose only one.

    Edit: Of course, if you have better choices (other than these two ) to recommend, please say it loudly

    This is not opinion, but fact.

    Any book on Java concurrency written in 1999 cannot cover the following:

    • the java.util.concurrent classes introduced in Java 5, and

    • the formalization of the Java Memory Model that came with the Java 5 language specification.

    Both of these topics are very important.

    If I have empirical data on what locks were acquired in what orders by which thread and line of code, how can I then use that data to determine if locking order has deadlock potential?

    l = lock u = unlock

    e.g.: these are in conflict and might deadlock

    thread 1: l1, l2, u2, u1
    thread 2: l2, l1, u1, u2
    

    Or even this single thread is in conflict with itself since I don't really know that the second half of the sequence wouldn't be run on a separate thread in a different use case.

    thread 1: l1, l2, u2, u1, l2, l1, u1, u2
    

    Is there a suitable algorithm that can be used to determine that from the data?

    Note I am asking not what to find (different lock aquisition orders), but what algorithm or data structure to use to find them given a set of empirical data.

    If I understand your problem correctly, you have just run into the classic lock-ordering deadlock problem.

    A program will be free of lock-ordering deadlocks if all threads acquire the locks they need in a fixed global order. (from Java Concurrency in Practice)

    If you detect in your data that different threads acquired the same locks in different order, then your program can potentially suffer a lock-ordering deadlock with unlucky timing. So that's the pattern to look for in your data; it's that simple.


    UPDATE: Here is an algorithm how I would do it. I don't know whether it has a name.

    For each lock event li from the left to right:

    • find its corresponding unlock event (or use the end of the sequence if it is never released)

    • add all enclosed lock events as pairs (i,j) where j is an enclosed lock event

    • then go to the next lock event and repeat.

    An example follows.

    enter image description here

    For example, for the first event lA it means scanning through the sequence to find the first occurrence of uA. This gives us the subsequence: lA lB uA. For each lock event in this subsequence add a pair into a set. In this case, save (A,B) in the set. (If we had another lock event in this subsequence, say
    lA lB lD uA, we would add the pair (A,D) as well to the set.)

    Now let's prepare the next subsequence. For the next lock event in the orgininal sequence, that is lB, find the first uB following it. This gives the subsequence is lB uA lC uB and the only pair that needs to be saved in the set is (B,C).

    For the third subsequence, for the lC event there is no pair to be saved as there is no lock event in the lC uB subsequence.

    The set of thread 1 contains the pairs (A,B) and (B,C). I would simple create another set containing the reversed pairs (B,A) and (C,B); let's call it the forbidden set.

    I would repeat this procedure for thread 2, prepare the container with the pairs telling which locks were acquired in what order by thread 2. Now, if the set intersection of this set and the forbidden set of thread 1 is not empty, then we have detected a potential lock-ordering deadlock.

    Hope this helps.

    I have a code similar to this which is inside run() method of a Runnable and multiple instances of that Runnable get launched,

    do{
            try{
                String contractNum=contractNums.take();
               }catch(InterruptedException e){
                logger.error(e.getMessage(), e);
            }
      }while(!("*".equals(contractNum)));
    

    Where contractNums is a BlockingQueue<String> shared by multiple threads. There are separate Runnables putting elements to this queue.

    I am not sure about next steps after catching InterruptedException, should I terminate this thread by re throwing a RuntimeException ( so my while loop terminates ) or try to take next element from contractNum queue again and ignoring InterruptedException?

    I am not sure if InterruptedException to be treated as a fatal condition for thread to terminate or keep it in while loop.

    Please suggest.

    7.1.2 Interruption policies

    Just as tasks should have a cancellation policy, threads should have an interruption policy. An interruption policy determines how a thread interprets an interruption request—what it does (if anything) when one is detected, what units of work are considered atomic with respect to interruption, and how quickly it reacts to interruption. The most sensible interruption policy is some form of thread-level or service- level cancellation: exit as quickly as practical, cleaning up if necessary, and pos- sibly notifying some owning entity that the thread is exiting. It is possible to establish other interruption policies, such as pausing or resuming a service, but threads or thread pools with nonstandard interruption policies may need to be restricted to tasks that have been written with an awareness of the policy.

    7.1.3 Responding to interruption

    As mentioned befor, when you call an interruptible blocking method such as Thread.sleep or BlockingQueue.put , there are two practical strategies for handling InterruptedException :

    • Propagate the exception (possibly after some task-specific cleanup), making your method an interruptible blocking method, too; or

    • Restore the interruption status so that code higher up on the call stack can deal with it.

    Java Concurrency in Practice Chapter 7.

    Specifically in your code you will need to make sure that if thread is interrupted your application logic is not broken. And it is indeed better to catch your interruption exception. What to with it is up to you just try to make sure that you don't break the application logic.

    I have a function that serially (single-threaded-ly) iterates through a directory of files, changing all tab indentation to three-space indentation.

    I'm using it as my first attempt at multi-threading. (Am most of the way through Java Concurrency in Practice...surprised it's eight years old now.)

    In order to keep it's current single-threaded functionality, but add in the additional possibility of multi-threading, I'm thinking of changing the function to accept an additional Executor parameter, where the original single-threaded function would now be a call to it, passing in a single threaded executor.

    Is this an appropriate way to go about it?

    One way is as @Victor Sorokin suggests in his answer: wrap the processing of every file in a Runnable and then either submit to an Executor or just invoke run() from the main thread.

    Another possibility is to always do the same wrapping in a Runnable and submit it to an always-given Executor.

    Whether processing of each file is executed concurrently or not would depend on the given Executor's implementation.

    For parallel processing, you could invoke your function passing it i.e. a ThreadPoolExecutor as an argument, whereas for sequential processing you could pass in a fake Executor, i.e. one that runs submitted tasks in the caller thread:

    public class FakeExecutor implements Executor {
    
        @Override
        public void execute(Runnable task) {
            task.run();
        }
    }
    

    I believe this way is the most flexible approach.

    I have an @ApplicationScoped bean for all users, that stores the ids-> names & vice versa in Trove & java.util maps.

    I just build the maps once at construction of bean or (in case of manual refresh by the website admin).

    Inside the bean methods, I am just using the get() with the maps, so not modifying the map. Is this going to be thread safe since it is used only for ready purposes? I am not sharing the maps with any other beans outside & not modifying the maps(adding/removing entries) anytime in my code.

    Also, Is it neccesary in this case to make the fields final ?

    Bean code as follows:

    @ApplicationScoped
    @ManagedBean(name="directory", eager=true)
    public class directory {
    
        private static TIntObjectHashMap<String> idsToNamesMap;
        private static TreeMap<String, Integer> namesToIdsMap;
    
        @PostConstruct
        public void buildDirectory(){
            // building directory here ....
        }
    
        public String getName(int topicId){
            return idsToNamesMap.get(topicId);
        }    
    
        public List<Entry<String, Integer>> searchTopicsByName(String query){
            return new ArrayList(namesToIdsMap.subMap(query, true, query+"z", true).entrySet());
        }        
    }
    

    There could be a visibility issue after the object is constructed. That is, in the immediate aftermath of your constructor calls, the maps may appear populated to the thread that populated them, but not necessarily to other threads, at least not right away. This type of issue is extensively discussed in chapter 3 of Java Concurrency in Practice. However, I think that if you declare the maps as volatile:

    private static volatile TIntObjectHashMap<String> idsToNamesMap;
    private static volatile TreeMap<String, Integer> namesToIdsMap;
    

    You should be OK.

    Update

    I just realized something while looking at your code again. The maps are static - why are they being populated in an instance context by a constructor? First off, it is confusing to the reader. Second, if more than one instance of the object is created, then you will have additional writes to the maps, not just one, possibly while other threads are reading them.

    You should either make them non-static, or populate them in a static initialization block.

    I have a number of shared variable x,y,z, all of which can modified in two different methods running in two different threads.(say method 1 in thread 1 and method 2 in thread 2) . If I declare these two methods as synchronized , does it guarantee the consistency of the variables x,y and z. Or should I separately use a lock on each of those variables?

    Yes, your approach will guarantee consistency, assuming those variables are all private and are not accessed (read or write) outside of the two synchronized methods.

    Note that if you read those variables outside of a synchronized block then you could get inconsistent results:

    class Foo {
        private int x;
    
        public synchronized void foo() {
            x = 1;
        }
    
        public synchronized void bar() {
            x = 2;
        }
    
        public boolean baz() {
            int a = x;
            int b = x;
            // Unsafe! x could have been modified by another thread between the two reads
            // That means this method could sometimes return false
            return a == b;
        }
    }
    

    EDIT: Updated to address your comment about the static variable.

    Each class should own its own data. If class A allows direct access to a variable (by making it public) then it is not owning its own data and it becomes very difficult to enforce thread safety.

    If you do this:

    class A {
        private static int whatever;
    
        public static synchronized int getWhatever() {
            return whatever;
        }
    
        public static synchronized void setWhatever(int newWhatever) {
            whatever = newWhatever;
        }
    }
    

    then you'll be fine.

    Remember that synchronized enforces a mutex on a single object. For synchronized methods it's this (or the Class object for static methods). Synchronized blocks on other objects will not interfere.

    class A {
        public synchronized void doSomething() {...}
    }
    class B {
        public synchronized void doSomethingElse() {...}
    }
    

    A call to doSomething will not wait for calls to doSomethingElse because they're synchronized on different objects: in this case, the relevant instance of A and the relevant instance of B. Similarly, two calls to doSomething on different instances of A will not interfere.

    I highly recommend that you take a look at Java Concurrency in Practice. It is an excellent book that explains all the subtleties of the Java thread and memory models.

    I have a web app where I load components lazily. There is a lot of

    static Bla bla;
    ...    
    if(bla == null) 
        bla = new Bla();
    

    spread throughout the code. What do I need to do to make sure this is thread safe? Should I just wrap anytime I do one of these initializations in a synchronized block? Is there any problem with doing that?

    The lazy instantiation is only really a part of the problem. What about accessing these fields?

    Typically in a J2EE application you avoid doing this kind of thing as much as you can so that you can isolate your code from any threading issues.

    Perhaps if you expand one what kind of global state you want to keep there are better ways to solve the problem.

    That being said, to answer your question directly, you need to ensure that access to these fields is done synchronized, both reading and writing. Java 5 has better options than using synchronized in some cases. I suggest reading Java Concurrency in Practice to understand these issues.

    I have gone through Head First Java and some other sites but I couldn't find complete stuff related to Threads and additional concurrency packages at one place.

    Please suggest a book/website which covers complete Threads with more details like

    • Synchronize and locking of objects
    • More detailed about volatile
    • Visibility issues in Threads
    • java.util.concurrent package
    • java.util.concurrent.atomic package

    Java Concurrency in Practice is great for coverage of the higher-level stuff in java.util.Concurrent, but if you want the authoritative answers on synchronized and volatile, you need to go to the source. No, not the source code, that would be insane. I mean the spec: Java Language Specification, Third Edition — Chapter 17: Threads and Locks

    Or if you want it in book form: The Java™ Language Specification (3rd Edition)

    The must-read book about concurrent programming in Java is Java Concurrency in Practice.

    Also see Concurrency in Sun's Java Tutorials.

    I have written a custom MyLogger library based on Observer design pattern. What I am trying to achieve is this: Every time I call writeLog(LOG_LEVEL,"Text") method I want it to execute in a new thread. Can someone please suggest what will be the way to achieve this. As in where shall I create threads.

    This is how my Logger call looks.

    public class Logger extends Subject{
         void writeLog(String type, String message)
            {       setData(message);
                    notifyy(type);
            }
    
    }
    

    And this is how I am calling writeLog

    appLogger.writeLog("ERROR", "This is error");
    

    You can use an ExecutorService

    // Somewhere in your logging framework
    ExecutorService service = Executors.new...(); // Choose the one you want
    ...
    
    public MessageRelayingTask implements Runnable {
        // private fields
        ...
    
        public MessageRelayingTask(String type, String message) {
             ...
        }
    
        @Override
        public void run() {
            setData(message);
            notifyy(type);
        }     
    }
    
    public class Logger extends Subject implements Runnable {
        void writeLog(String type, String message) {
            service.submit(new MessageRelayingTask(type, message));
        }
    }
    

    Some pointers to get you started:

    I'm having trouble setting up Spring with Hibernate under GWT framework. I am fairly new to GWT. I have the application context set up and loading without output errors, but my main issue at the moment is that the my Service layer implementation (PobaseServiceImpl) requires a DAO that I set up in the appcontext but its not wrapping the DAO. Naturally my RPC is attempting to call the dao methods resulting in a NullPointerException. The pobaseDao is not being set by the TransactionProxyFactoryBean when I initialize it.

    In summary: The DAO should be created by (that is, configured into) Spring just like the rest of my services. Then injected to the services via Spring. Then with the DAO, wrap it in a Spring transaction proxy (org.springframework.transaction.interceptor.TransactionProxyFactoryBean) and give it a Hibernate SessionFactory (org.springframework.orm.hibernate4.LocalSessionFactoryBean). But for some reason its not setting the dao

    So my application context is being loaded through a ServletContextListener. Here is my application context:

    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
    
      <!--
        Spring Framework application context definition for the POBASE Website.
      -->
    
    <beans>
    
      <!-- Configurer that replaces ${...} placeholders with values from a properties file -->
      <bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
        <property name="locations">
          <list>
             <value>classpath:/pobase.properties</value>
             <value>file:${user.home}/pobase.properties</value>
          </list>
        </property>
        <property name="ignoreResourceNotFound" value="no"/>
      </bean>
    
      <!-- Hibernate Data Source -->
      <bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
        <property name="driverClassName" value="${pobase.database.driver}" />
        <property name="url" value="${pobase.database.url}" />
        <property name="username" value="${pobase.database.user}" />
        <property name="password" value="${pobase.database.password}" />
      </bean>
    
      <!-- Hibernate SessionFactory -->
      <bean id="sessionFactory" class="org.springframework.orm.hibernate4.LocalSessionFactoryBean">
        <property name="dataSource">
          <ref bean="dataSource" />
        </property>
        <property name="packagesToScan" value="nz.co.doltech.pobase.client.entity"/>
        <property name="hibernateProperties">
          <props>
            <prop key="hibernate.dialect">${pobase.hibernate.dialect}</prop>
            <prop key="hibernate.show_sql">${pobase.hibernate.show_sql}</prop>
            <prop key="javax.persistence.validation.mode">none</prop>
          </props>
        </property>
      </bean>
    
      <!-- Transaction manager for a single Hibernate SessionFactory (alternative to JTA) -->
      <bean id="transactionManager" class="org.springframework.orm.hibernate4.HibernateTransactionManager">
        <property name="sessionFactory" ref="sessionFactory" />
      </bean>
    
      <!-- Default transaction proxy, defining the transactional behaviour for
        a typical Dao configuration -->
      <bean id="baseDaoTransactionProxy" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"
        abstract="true">
        <property name="transactionManager" ref="transactionManager" />
        <property name="transactionAttributes">
          <value>*=PROPAGATION_MANDATORY</value>
        </property>
      </bean>
    
      <!-- Default transaction proxy, defining the transactional behaviour for
        a typical Service configuration -->
      <bean id="baseServiceTransactionProxy" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"
        abstract="true">
        <property name="transactionManager" ref="transactionManager" />
        <property name="transactionAttributes">
          <value>*=PROPAGATION_REQUIRED</value>
        </property>
      </bean>
    
      <!-- ========================= BUSINESS OBJECT DEFINITIONS ========================= -->
    
      <bean id="pobaseDao" parent="baseDaoTransactionProxy">
        <property name="target" ref="pobaseDaoTarget" />
      </bean>
      <bean id="pobaseDaoTarget" class="nz.co.doltech.pobase.server.dao.PobaseHibernateDao">
        <property name="sessionFactory" ref="sessionFactory" />
      </bean>
    
      <bean id="pobaseService" parent="baseServiceTransactionProxy">
        <property name="target" ref="pobaseServiceTarget" />
      </bean>
      <bean id="pobaseServiceTarget" class="nz.co.doltech.pobase.server.service.PobaseServiceImpl">
        <property name="pobaseDao" ref="pobaseDao" />
        <!-- property name="accessControlService" ref="accessControlService" />
        <property name="lookupService" ref="lookupService"/>
        <property name="notificationService" ref="notificationService"/ -->
      </bean>
    
    </beans>
    

    and here is my RPC servlet implementation:

    package nz.co.doltech.pobase.server.service;
    
    /**
     * Extends RSS and implements the PobaseService
     * @author Ben
     */
    @SuppressWarnings("serial")
    public class PobaseServiceImpl extends RemoteServiceServlet implements PobaseService {
    
        @SuppressWarnings("unused")
        private static final Logger logger = Logger.getLogger(PobaseServiceImpl.class.getName());
    
        private PobaseDao pobaseDao;
        private final HashMap<Integer, PobaseEntity> pobaseEntities = new HashMap<Integer, PobaseEntity>();
    
        private void fetchExternPobase()
        {
            pobaseEntities.clear();
            List<PobaseEntity> pobaseList = pobaseDao.getAllPobase();
            for (int i = 0; i < pobaseList.size(); i++)
            {
                PobaseEntity en = pobaseList.get(i);
                if(en != null) {
                    pobaseEntities.put(en.getId(), en);
                }
            }
        }
    
        public void setPobaseDao(PobaseDao dao)
        {
            this.pobaseDao = dao;
        }
    
        public PobaseDao getPobaseDao()
        {
            return this.pobaseDao;
        }
    
        public PobaseData addLocalPobase(PobaseData pobase)
        {
            PobaseEntity entity = new PobaseEntity();
            entity.mirrorObjectData(pobase);
    
            pobase.setId(pobaseEntities.size());
            pobaseEntities.put(pobase.getId(), entity); 
    
            return entity.getDataObject();
        }
    
        public PobaseData updateLocalPobase(PobaseData pobase)
        {
            PobaseEntity entity = new PobaseEntity();
            entity.mirrorObjectData(pobase);
    
            pobaseEntities.remove(entity.getId());
            pobaseEntities.put(entity.getId(), entity);
    
            return entity.getDataObject();
        }
    
        public Boolean deleteLocalPobase(int id)
        {
            pobaseEntities.remove(id);
            return true;
        }
    
        public ArrayList<PobaseData> deleteLocalPobases(ArrayList<Integer> ids)
        {
            for (int i = 0; i < ids.size(); ++i) {
                deleteLocalPobase(ids.get(i));
            }
    
            return getLocalPobaseData();
        }
    
        public ArrayList<PobaseData> getLocalPobaseData()
        {
            ArrayList<PobaseData> pobaseList = new ArrayList<PobaseData>();
            Iterator<Integer> it = pobaseEntities.keySet().iterator();
            while(it.hasNext())
            {
                PobaseData pobase = pobaseEntities.get(it.next()).getDataObject();
                pobaseList.add(pobase);
            }
            return pobaseList;
        }
    
        public PobaseData getLocalPobase(int id)
        {
            return pobaseEntities.get(id).getDataObject();
        }
    
        public ArrayList<PobaseData> resyncExternPobase()
        {
            fetchExternPobase();
            return getLocalPobaseData();
        }
    
    }
    

    Also here is the start-up log for the web application:

    ServletContextListener started
    Nov 12, 2012 8:20:33 PM nz.co.doltech.pobase.SpringInitialiser initSpringContext
    INFO: Creating new Spring context. Configs are [/nz/co/doltech/pobase/appcontext.xml]
    Nov 12, 2012 8:20:33 PM org.springframework.context.support.AbstractApplicationContext prepareRefresh
    INFO: Refreshing org.springframework.context.support.ClassPathXmlApplicationContext@8423321: startup date [Mon Nov 12 20:20:33 NZDT 2012]; root of context hierarchy
    Nov 12, 2012 8:20:33 PM org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions
    INFO: Loading XML bean definitions from class path resource [nz/co/doltech/pobase/appcontext.xml]
    Nov 12, 2012 8:20:33 PM org.springframework.core.io.support.PropertiesLoaderSupport loadProperties
    INFO: Loading properties file from class path resource [pobase.properties]
    Nov 12, 2012 8:20:33 PM org.springframework.core.io.support.PropertiesLoaderSupport loadProperties
    INFO: Loading properties file from URL [file:/home/ben/pobase.properties]
    Nov 12, 2012 8:20:33 PM org.springframework.beans.factory.support.DefaultListableBeanFactory preInstantiateSingletons
    INFO: Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@4c56666d: defining beans [org.springframework.beans.factory.config.PropertyPlaceholderConfigurer#0,dataSource,sessionFactory,transactionManager,baseDaoTransactionProxy,baseServiceTransactionProxy,pobaseDao,pobaseDaoTarget,pobaseService,pobaseServiceTarget]; root of factory hierarchy
    Nov 12, 2012 8:20:33 PM org.springframework.jdbc.datasource.DriverManagerDataSource setDriverClassName
    INFO: Loaded JDBC driver: org.postgresql.Driver
    Nov 12, 2012 8:20:33 PM org.hibernate.annotations.common.Version <clinit>
    INFO: HCANN000001: Hibernate Commons Annotations {4.0.1.Final}
    Nov 12, 2012 8:20:33 PM org.hibernate.Version logVersion
    INFO: HHH000412: Hibernate Core {4.1.7.Final}
    Nov 12, 2012 8:20:33 PM org.hibernate.cfg.Environment <clinit>
    INFO: HHH000206: hibernate.properties not found
    Nov 12, 2012 8:20:33 PM org.hibernate.cfg.Environment buildBytecodeProvider
    INFO: HHH000021: Bytecode provider name : javassist
    Nov 12, 2012 8:20:34 PM org.hibernate.dialect.Dialect <init>
    INFO: HHH000400: Using dialect: org.hibernate.dialect.PostgreSQLDialect
    Nov 12, 2012 8:20:34 PM org.hibernate.engine.jdbc.internal.LobCreatorBuilder useContextualLobCreation
    INFO: HHH000424: Disabling contextual LOB creation as createClob() method threw error : java.lang.reflect.InvocationTargetException
    Nov 12, 2012 8:20:34 PM org.hibernate.engine.transaction.internal.TransactionFactoryInitiator initiateService
    INFO: HHH000399: Using default transaction strategy (direct JDBC transactions)
    Nov 12, 2012 8:20:34 PM org.hibernate.hql.internal.ast.ASTQueryTranslatorFactory <init>
    INFO: HHH000397: Using ASTQueryTranslatorFactory
    Nov 12, 2012 8:20:34 PM org.springframework.orm.hibernate4.HibernateTransactionManager afterPropertiesSet
    INFO: Using DataSource [org.springframework.jdbc.datasource.DriverManagerDataSource@55acc0d4] of Hibernate SessionFactory for HibernateTransactionManager
    Starting Jetty on port 8888
    

    Anyone have any ideas as to why its not working? Some specs here:

    • Spring 3.2.0
    • Hibernate4
    • GWT SDK 2.4.0

    Appreciate any help I can get!

    Cheers, Ben

    Your PobaseServiceImpl class is not thread-safe. In Java any remote called service(and of course the same goes the singletons in the container too)should be prepared that its methods will be called from the different threads and the same method can be executed simultaneously in the different threads.

    The entire class needs a detailed check.

    First of all, you should use ConcurrentHashMap instead of HashMap. And all methods need to be carefully rewritten - for example the method that return ArrayList ( public ArrayList<PobaseData> resyncExternPobase()) should make a defensive copy of the data.

    As an alternative you should consider making the public methods your service methods synchronized, however, that will force the methods to be executed sequentially and that will undermine performance if the service is expected to be actively used from the different threads.

    For the reference, consider reading Brian Goetz Java Concurrency In Practice, chapter 5. Building Blocks and especially 5.1 Synchronized collections and 5.2. Concurrent collections

    update: Your PobaseServiceImpl seems to be a servlet that is instantiated by the servlet container - to populate its fields with Spring beans you're you should use Spring utility methods - for example WebApplicationContextUtils - there are many examples in the internet, like http://pgt.de/2009/07/17/non-invasive-gwt-and-spring-integration-reloaded/

    I'm reading a book which says not to use such a code:

    private volatile Thread myThread;
    
    ....
    
    myThread.stop();
    

    Instead one should use:

    if (myThread != null ) {
    
     Thread dummy = myThread;
    
     myThread = null;
    
     dummy.interrupt();
    
    
    }
    

    Unfortunately the subject is not elaborated any further... Could someone explain me this?

    stop() is deprecated. Never never and never use stop(). You can use java concurrency instead.

    From Javadoc :

    This method is inherently unsafe. Stopping a thread with Thread.stop causes it to unlock all of the monitors that it has locked (as a natural consequence of the unchecked ThreadDeath exception propagating up the stack). If any of the objects previously protected by these monitors were in an inconsistent state, the damaged objects become visible to other threads, potentially resulting in arbitrary behavior. Many uses of stop should be replaced by code that simply modifies some variable to indicate that the target thread should stop running. The target thread should check this variable regularly, and return from its run method in an orderly fashion if the variable indicates that it is to stop running. If the target thread waits for long periods (on a condition variable, for example), the interrupt method should be used to interrupt the wait.

    Have a look at Java Concurrency in Practice chapter 7 (Cancellation and Shutdown)

    I'm trying to convert existing single thread flood fill algorithm(s) to multithread one(s).

    Input: - 2d bit array and its dims - xy coords where fill should begin

    Output: - same 2d bit array with updated bits

    Problem: - only 1 thread at the time can write to given 64bits (8x8 pixels) in array, also no other thread can read this 64bits chunk at the write time

    I've started with queue approach and thread pool so once thread finishes its job it can take another task from the queue.

    How would you organize thread synchronization conforming 'problem' statement?

    The main problem is how to assign read/write lockers to given memory chunk?

    Generally you want to divide the data as coarsely as possible and minimize communication between threads. Communication includes shared data structures, even the lock free ones. Especially the ones where there are shared variables with write access.

    Above general "coarse" policy avoids the common pitfalls (for example false sharing) which prevent scaling.

    As for your specific problem, I have to confess, I'm not intimate with flood fill algorithms so I'm not immediately able to sketch out a coarse approach.

    However if a coarse approach is not feasible and a strategy for locking individual cells is needed, lock striping could be an approach worth investigating in this case.

    A lock free implementation is another possibility. Maybe use compare-and-swap type operation to do the writes (InterlockedCompareExchange64 on VS) combined with retry logic if another thread wrote in the same 8x8 pixel 64bit block.

    It could be possible to relax the read locking completely. If 2 threads end up painting the same pixels, it may only waste some cycles, but not corrupt the results.

    A lock free implementation could be several times faster.

    If you are working in Java Java Concurrency in Practice by Goetz is a great book on things like lock striping.

    I'm used to C++/Qt's concept of signals (emit/listen) and now I'm doing a project in Java which requires some sort of data sending/receiving mechanism.

    My needs are:

    • Emit an event (with some data) and let all threads listen/catch it.
    • Obviously, given the previous requirement, being able to listen/catch signals with attached data.

    Is this possible in Java, and how? (I'll appreciate a small compilable example/link)

    Java by default doesn't have a simple event handling mechanism such as .Net's events or Qt's Signals and Slots. It does have the notion of Listeners in various java GUI frameworks but I don't think that's what you're looking for.

    You should consider a pub-sub library like Google Guava's EventBus framework.

    If you don't want to use a third party lib then I suggest you start looking into using one of the sub-classes of BlockingQueue. See the FileCrawler example from page 62 of Java Concurrency in Practice to see how to use a BlockingQueue to send events/data to worker threads.

    If you're looking for a more complicated solution for message/event notifications across the process boundary or the local machine boundary then you may want to look into:

    I'm using a third party library in my thread which involves some heavy DB operations . Sometimes due to the lock on the DB or any other reasons execution of thread gets stuck . I want to kill the thread irrespective of what it is doing after the particular time interval. Thread.interrupt() is not working out for me because my thread spend most of its time in the third party library which i can't modify and library doesn't throw any Interrupted Exception which i can handle in my code. Thread.stop() is not advised to use since it is deprecated . But i have to kill the thread anyway

    void mainThread()
    {
      Thread1 t1 = new Thread1();
      t1.start();
      Thread.sleep(time);
      if(t1.getState() != State.TERMINATED)
      {
        // code for killing the thread
      }
    }
    
    Thread1()
    {
        //doing heavy DB operations using third party Library
    }
    

    Any suggestion for other designs is welcomed . Is there any alternate method for killing a thread instead of thread.stop()

    Wrap your DB access in a FutureTask and get the result using FutureTask.get(long, TimeUnit) (it will return before the supplied time, or throw a TimeoutException).

    Read Chapter 6 of Java Concurrency in Practice by Brian Goetz et al for more info

    I'm working on small CRUD application that use plain JDBC, with a Connection enum-based singleton, after reading the first part of Java Concurrency in Practice I just liked the ThreadLocalapproach to write thread-safe code, my question is :

    When wrapping global JDBC connection in a ThreadLocal considered a good practice ?

    When wrapping global JDBC connection in a ThreadLocal considered a good practice ?

    Depends a lot on the particulars. If there are a large number of threads then each one of them is going to open up their own connection which may be prohibitive. Then you are going to have connections that stagnate as threads lie dormant.

    It would be better to use a reentrant connection pool. Then you can reuse connections that are already open but not currently in use but limit the number of connections to the minimum you need to work concurrently. Apache's DBCP is a good example and is well thought of.

    To quote from their docs:

    Creating a new connection for each user can be time consuming (often requiring multiple seconds of clock time), in order to perform a database transaction that might take milliseconds. Opening a connection per user can be unfeasible in a publicly-hosted Internet application where the number of simultaneous users can be very large. Accordingly, developers often wish to share a "pool" of open connections between all of the application's current users. The number of users actually performing a request at any given time is usually a very small percentage of the total number of active users, and during request processing is the only time that a database connection is required.

    I'm writing an application that calculates delta and roots of a second degree equation, accepting its coefficients as input. Later, i want to give it a GUI.

    This is the class that calculates everything:

    package functions;
    
    import java.util.*;
    
    public class Calculate implements Runnable {
    double a=0;
    double b=0;
    double c=0;
    double delta = 0;
    double r1=0;
    double r2=0;
    Vector data=new Vector ();
    
    public Calculate (Vector v) {
        synchronized (data) {
            synchronized (v) {
                data = v;
            }
            a =(double) data.elementAt(0);
            b =(double) data.elementAt(1);
            c =(double) data.elementAt(2);
        }
    }
    public double calcDelta () {
        delta = b*b-4*a*c;
        return delta;
    }
    public double root1 () {
        r1 = (-b+Math.sqrt(delta))/(2*a);
        return r1;
    }
    public double root2 () {
        r2 = (-b-Math.sqrt(delta))/(2*a);
        return r2;
    }
    public void createData (Vector z) {
        synchronized (z) {
            while (z.size()!=0) {
                z.removeElementAt(0);
            }
            z.add(delta);
            z.add(r1);
            z.add(r2);
        }
    
    }
    public void run () {
        calcDelta();
        root1 ();
        root2 ();
        //try {
            createData (data);
        //} catch (InterruptedException e) {}
    }
    }
    

    which i tested and is working well. The problem is in the test code i wrote for it:

    import java.util.*;
    
    import functions.*;
    
    public class Test {
    double a=0;
    double b=0;
    double c=0;
    Vector v = new Vector ();
    public Test (double arturo, double bartolomeo, double cirinci) {
        a=arturo;
        b=bartolomeo;
        c=cirinci;
        synchronized (v) {
            v.add(a);
            v.add(b);
            v.add(c);
        }
    }
    public Vector makevector () {
        return v;
    }
    public static void main (String [] args) {
        double art = (double) Integer.parseInt (args[0]);
        double bar = (double) Integer.parseInt (args[1]);
        double car = (double) Integer.parseInt (args[2]);
    
        Test t = new Test (art, bar, car);
    
        Thread launch;
        Vector data = t.makevector();
        Calculate res = new Calculate (data);
        launch = new Thread (res);
    
        launch.start();
    
        if (data.size()!=0) {
            System.out.println ("Delta: "+data.elementAt(0));
            System.out.println ("Radice 1: "+data.elementAt(1));
            System.out.println ("Radice 2: "+data.elementAt(2));
        }
    }
    }
    

    and specifically in the output for Delta. In facts, roots are correctly shown, but instead of delta, it prints the a coefficient (by example, if i pass 1 1 -6, i expect delta to be 25, but it shows 1; if it s 2 2 -12 delta hould still be 25, but it shows 2). Somehow, the first element of this vector doesn't get deleted and replaced, but i don't know why; i just know it's not a matter of synchronisation, since i tried to delete all of the syncs and the output was the same.

    So, what's my mistake? Thank you.

    Your problem is (probably) that the calculations haven't finished before you print them.

    Take a look at this part of your code:

    launch.start();
    
    if (data.size()!=0) {
        System.out.println ("Delta: "+data.elementAt(0));
        System.out.println ("Radice 1: "+data.elementAt(1));
        System.out.println ("Radice 2: "+data.elementAt(2));
    }
    

    When you do launch.start() the calculations start but in other thread, and this thread is still runing, so it starts to print the elements of data Vector. And those elements weren't updated yet.

    Try adding Thread.sleep(2000); before the if (data.size()!=0) and see if the results change to what you would expect. This way you will make one thread to finish it's job before the other one prints the output. This is not the solution of course - it will only show where the problem lies. If you want a solution look at java.util.concurrent and there you can finds something useful like CoundDownLatch.

    Moreover you're using the synchronized keyword much to often and not necessarly proper. You should be always careful with using synchronized. Try this book:

    http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601

    but keep in mind that concurrency in Java is quite advanced subject.

    I needed to use these nested class because nested class can use the variable from the class been nested. How do I move these class to a something.java to simplify my code and the class still have the control of the gui class , such as Jlabel?

    this is the cleaned version to show the important part

    public class GUI {
    
            public GUI(){
    
                VitaminDEngineStarter vdes = new VitaminDEngineStarter();
                Registry registry = null;
                try {
                    registry = LocateRegistry.getRegistry();
                } catch (RemoteException e1) {
                    // TODO Auto-generated catch block
                    e1.printStackTrace();
                }
    
                try {
                    vd = (VitaminD)registry.lookup(VitaminD.SERVICE_NAME);
                } catch(Exception e) {
                    e.printStackTrace();
                }
    
    
    
                SMS a = new SMS(5);
                try {
                    arduino.connect("COM3");
                } catch (Exception e) {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                }
                System.out.println("connecting:"+ a.connect());
                System.out.println("connected? :" + a.checkConnect());
                System.out.println("signal: "+a.checkSignal());
                System.out.println("deliver report :" + a.DeliveryReportOn());
                SMS.Read read = a.new Read(arduino);
    
    
            }
    
            class ShowSense implements Runnable {
    
    
                @Override
                public void run() {
                    String[] temp;
                    String light = "";
                    String temperature = "";
                    String hum = "";
                    String sens = "";
                    boolean humanact = false;
    
                    // TODO Auto-generated method stub
                    while (true){
                        try {
                            humanact = vd.gethumanActivity();
                        } catch (RemoteException e) {
                            // TODO Auto-generated catch block
                            e.printStackTrace();
                        }
                        sens = arduino.getSensor();
                        temp = sens.split(",");
                        light = temp[1];
                        temperature = temp[0];
                        hum = temp[2];
    
                        LightIntensity.setText(light);
                        Temperature.setText(temperature);
                        humidity.setText(hum);
    
    
                        if (humanact){
                            personActivity.setText("in place");
                        }
                        else{
                            personActivity.setText("absent");
                        }
    
                    }
                }
    
            }
    
            private JPanel getInputs() {
                if (Inputs == null) {
                    personActivity = new JLabel();
                    personActivity.setBounds(new Rectangle(114, 137, 77, 27));
                    personActivity.setText("");
                    personActivityLabel = new JLabel();
                    personActivityLabel.setBounds(new Rectangle(7, 137, 99, 25));
                    personActivityLabel.setText("Person Activity:");
                    humidity = new JLabel();
                    humidity.setBounds(new Rectangle(106, 91, 84, 27));
                    humidity.setText("");
                    humidityLabel = new JLabel();
                    humidityLabel.setBounds(new Rectangle(6, 92, 88, 26));
                    humidityLabel.setText("Humidity:");
                    Temperature = new JLabel();
                    Temperature.setBounds(new Rectangle(101, 50, 89, 30));
                    Temperature.setText("");
                    TemperatureLabel = new JLabel();
                    TemperatureLabel.setBounds(new Rectangle(4, 50, 91, 30));
                    TemperatureLabel.setText("Temperature:");
                    LightIntensity = new JLabel();
                    LightIntensity.setBounds(new Rectangle(110, 6, 84, 34));
                    lightLabel = new JLabel();
                    lightLabel.setBounds(new Rectangle(5, 5, 97, 34));
                    lightLabel.setText("Light Intensity:");
                    Inputs = new JPanel();
                    Inputs.setLayout(null);
                    Inputs.setBounds(new Rectangle(14, 63, 200, 183));
                    Inputs.add(lightLabel, null);
                    Inputs.add(LightIntensity, null);
                    Inputs.add(TemperatureLabel, null);
                    Inputs.add(Temperature, null);
                    Inputs.add(humidityLabel, null);
                    Inputs.add(humidity, null);
                    Inputs.add(personActivityLabel, null);
                    Inputs.add(personActivity, null);
                    th.start();
                }
                return Inputs;
            }
    
            class autopilotthread implements Runnable{
    
                /** The temp. */
                private String[] temp;
    
                /** The lightintensty. */
                private double lightintensty ;
    
                /** The temperature. */
                private double temperature ;
    
                /** The hum. */
                private double hum ;
    
                /** The sens. */
                private String sens = null;
    
                /** The humanact. */
                private double humanact;
    
                /** The result. */
                private boolean [] result = {false , false};
    
                /** The fan. */
                private boolean fan =false;
    
                /** The light. */
                private boolean light = false;
    
                /** The pstop. */
                boolean pstop = false;
    
                /* (non-Javadoc)
                 * @see java.lang.Runnable#run()
                 */
                @Override
                public void run() {
                    System.out.println("thread start!");
                    while(true){
                        System.out.println("thread loop!");
                            try {
                                if(vd.gethumanActivity()){
                                    humanact = 250;
                                }else{
                                    humanact = 0;
                                }
                            } catch (RemoteException e) {
                                // TODO Auto-generated catch block
                                e.printStackTrace();
                            }
                            sens = arduino.getSensor();
                            temp = sens.split(",");
                            lightintensty = Double.parseDouble(temp[1]);
                            temperature = Double.parseDouble(temp[0]);
                            hum = Double.parseDouble(temp[2]);
                            double [] out ={humanact ,lightintensty , hum, Time.now(),temperature };
                            System.out.println(""+out[0]+" "+out[1]+" "+out[2]+" "+out[3]+" "+out[4]);
                            result = Matlab.output(out);
                            light = result[1];
                            fan = result[0];
                            System.out.println("light:" + light);
                            System.out.println("fan:" + fan );
                            if(light){
                                try {X10.lightsOn();} 
                                catch (IOException e) {e.printStackTrace();}
    
                            }else{
                                try {X10.lightsOff();} 
                                catch (IOException e) {e.printStackTrace();}
    
                            }
    
                            if(fan){
                                try {X10.fanOn();} 
                                catch (IOException e) {e.printStackTrace();}
    
                            }else{
                                try {X10.fanOff();} 
                                catch (IOException e) {e.printStackTrace();}
    
                            }
    
    
    
                        try {TimeUnit.SECONDS.sleep(10);} 
                        catch (InterruptedException e) {e.printStackTrace();}
    
                        if (pstop){
                            break;
                        }
                    }
                    System.out.println("thread stop!");
    
                }
    
            }
    
            class Pilotmouse implements MouseListener{
    
                /** The p thread. */
                autopilotthread pThread = null;
    
                /** The pt. */
                Thread pt = null; 
    
                /**
                 * Instantiates a new pilotmouse.
                 */
                Pilotmouse(){
    
                }
    
                /* (non-Javadoc)
                 * @see java.awt.event.MouseListener#mouseClicked(java.awt.event.MouseEvent)
                 */
                @Override
                public void mouseClicked(MouseEvent arg0) {
                    // TODO Auto-generated method stub
    
                }
    
                /* (non-Javadoc)
                 * @see java.awt.event.MouseListener#mouseEntered(java.awt.event.MouseEvent)
                 */
                @Override
                public void mouseEntered(MouseEvent arg0) {
                    // TODO Auto-generated method stub
    
                }
    
                /* (non-Javadoc)
                 * @see java.awt.event.MouseListener#mouseExited(java.awt.event.MouseEvent)
                 */
                @Override
                public void mouseExited(MouseEvent arg0) {
                    // TODO Auto-generated method stub
    
                }
    
                /* (non-Javadoc)
                 * @see java.awt.event.MouseListener#mousePressed(java.awt.event.MouseEvent)
                 */
                @Override
                public void mousePressed(MouseEvent arg0) {
                    // TODO Auto-generated method stub
    
                }
    
                /* (non-Javadoc)
                 * @see java.awt.event.MouseListener#mouseReleased(java.awt.event.MouseEvent)
                 */
                @Override
                public void mouseReleased(java.awt.event.MouseEvent e) {
                    if ((autopilotlable.getText().equalsIgnoreCase("off"))){
                        autopilotlable.setText("on");
                        pThread = new autopilotthread();
                        pt = new Thread(pThread); 
                        pt.start();
    
                    } else if ((autopilotlable.getText().equalsIgnoreCase("on"))){
                        autopilotlable.setText("off");
                        pThread.pstop = true;
                    }
                }
    
            }
    
    
            private JButton getAutopilot() {
    
    
                if (autopilot == null) {
                    autopilot = new JButton();
                    autopilot.setBounds(new Rectangle(18, 14, 112, 28));
                    autopilot.setText("Auto Pilot");
    
                    autopilot.addMouseListener(new Pilotmouse());
                }
                return autopilot;
            }
    
    
            public static void main(String[] args) {
                SwingUtilities.invokeLater(new Runnable() {
                    public void run() {
                        GUI application = new GUI();
                        application.getJFrame().setVisible(true);
                    }
                });
    
            }
    
        }
    

    As Jochen mentioned you could use Eclipse Refactoring Tools. That won't solve design issues though.

    Generally:

    • GUI knows about 14 classes and acts as big mediator... Is it possible to group logic into some higher level classes and have GUI use them?
    • Your code mixes object construction with logic. Try to move those actions to different places
    • Don't start a thread inside constructor!
    • Revise usage of logical statements. Eg. : while(true){ ... if (pstop){ break; }}
    • Is X10 3rd party class or your own? If it's yours try to remove global state(eg use single instance of X10 and instance variables for state change. Not static ones)

    The most important advise: Please try to write unit tests for this functionality first using (for example) junit and mockito, and good design will come naturally. Believe me!

    EDIT:

    Good talk about JMM

    Good book about concurrency.

    EDIT:

    The Clean Code Talks - "Global State and Singletons"

    I need to create a File System Manager (more or less) which can read or write data to files.

    My problem is how do I handle concurrency?

    I can do something like

    public class FileSystemManager {
    
        private ReadWriteLock readWriteLock = new ReentrantReadWriteLock();
    
        public byte[] read(String path) {
            readWriteLock.readLock().lock();
            try {
                ...
            } finally {
                readWriteLock.readLock().unlock();
            }
        }
        public void write(String path, byte[] data) {
            readWriteLock.writeLock().lock();
            try {
                ...
            } finally {
                readWriteLock.writeLock().unlock();
            }
        }
    }
    

    But this would mean all access to the write (for example) will be locked, even if the first invocation is targeting /tmp/file1.txt and the second invocation is targeting /tmp/file2.txt.

    Any ideas how to go about this?

    I would look deeply into Java 5 and the java.util.concurrent package. I'd also recommend reading Brian Goetz' "Java Concurrency in Practice".

    I need to know that how to create Thread Object other than Extending Thread Class or Implementing Runnable Interface.

    This Question was ask in One of my Interview.

    Thanks

    Ever since Java 1.5, you should not create threads manually, you should use high level concurrency tools (see for example Effective Java Item 68: Prefer executors and tasks to threads).

    See the Executors page of the Oracle Concurrency trail or better yet, read Java Concurrency in Practice.

    I tried to make a event dispatcher in Java that will dispatch events as threads. So all the EventListener classes are essentially implemented the Runnable class. Like how firing of events work traditionally, a method in the event dispatcher class loops through a list of EventListeners and then invoke their handler method, except that this time, I invoke these handler as threads by putting the listeners into new Thread(handlerObject).start(). The actual handling is done in the run() method in the EventListener.

    So it looks something like:

    for(EventListener listener : listenerList) {
       if(listener instanceof Runnable)
          new Thread(listener).start();
    }
    

    So all instructions to handle the event in the listener are put inside the run() method, which will be executed when the thread.start().

    But the problem is the threads often go into a situation where one of the threads got stuck somewhere and didn't manage to continue. Sometimes, several threads may also get stuck while some managed to run through all instructions in the run() method in the listener. I looked up and this sounds like what it is called a deadlock.

    I tried to put the "synchronized" modifier to all my methods but it still has this problem. I thought the synchronized keyword would simply just queue any threads trying to run a similar method until a current thread running the method has finished. But this doesn't solve the problem still. Why doesn't synchronized solve the problem especially when I already have it on all my methods and it should queue any concurrent access that may potentially cause a deadlock? I didn't use any wait() or notify() methods. Just a simple event dispatcher that attempts to run its event listener as a thread.

    I am pretty new to threads but have found it very difficult to even debug it because I don't know where has gone wrong.

    Thanks for any help.

    Your real problem is that you don't understand concurrency well enough to understand why your program is not working, let alone how to solve this. (FWIW - adding synchronized to all of your methods is only making the problem worse.)

    I think that your best plan is take time out to do some reading on concurrency in Java. Here are a couple of good references:


    @wheaties has a micro-explanation of what a deadlock is, and @matt_b offers useful advice on how to diagnose a deadlock. However, these won't help a lot unless you know the right way to design and write your multi-threaded code.

    I want to know about the threading concept in BlackBerry.

    In Android we have async task or handlers to communicate. Is there something similar available in BlackBerry? How do two threads communicate? How do you pass data from a background thread to the UI thread?

    Concurrency is not a trivial thing. It's really difficult to craft a Thread-safe solution. In Blackberry Java the situation is even worse, as only JavaME Threading APIs are available, meaning you can't use all the Java SE high level classes (like executors, locks, collections, etc).

    My advice would be not to try to port Android's AsyncTask or any other high level concurrency-related class on your own, since very likely you'll make mistakes (unless you are well versed in concurrent programming). I myself would avoid it as much as possible. Instead keep the concurrent code as simple and small as you can. Most of the times all you need is to refresh the GUI from a worker thread. This can be done easily with UiApplication.invokeLater and UiApplication.invokeAndWait, and you don't need to write concurrent code at all.

    If you want to learn more about concurrency, I'd start with this tutorial by Oracle. It's aimed for JavaSE, but almost the first half is useful for JavaME as well. In case you want to learn more advanced concurrent programming, this book is a must read.

    maybe someone could recommend some good examples concerning thread executions, thread management. Maybe not only examples but article, tutorial if you will with examples.

    Generally I have a problem where I need to download a bunch of files from the web, but connection is limited to two. So when I gather up all the url's to files I need, I'd like to download say... 100 files but do so in async manner by two until all the threads finish their job.

    Thank, you for support.

    I don't have an article, but I do know of a good book that covers general multi-threaded programming using Java. It is called Java Concurrency in Practice. It does cover general usage patterns, etc.

    Maybe this is a recurrent question, but I need some customization with my context.

    I'm using Spring Batch 3.0.1.RELEASE

    I have a simple job with some steps. One step is a chunk like this:

        <tasklet transaction-manager="myTransactionManager">
    <batch:chunk reader="myReader" processor="myProcessor" writer="myWriter" commit-interval="${commit.interval}">
    </batch:chunk>
    

    <bean id="myProcessor" class="org.springframework.batch.item.support.CompositeItemProcessor" scope="step">
    <property name="delegates">
        <list>
            <bean class="...MyFirstProcessor">
            </bean>
            <bean class="...MySecondProcessor">
            </bean>
        </list>
    </property>
    

    • Reader: JdbcCursorItemReader
    • Processor: CompositeProcessor with my delegates
    • Writer: CompositeWriter with my delegates

    With this configuration, my job works perfectly.

    Now, I want to convert this to a multi-threaded job. Following the documentation to basic multi-thread jobs, I included a SympleAsyncTaskExecutor in the tasklet, but it failed.

    I have readed JdbcCursorItemReader does not work properly with multi-thread execution (is it right?). I have changed the reader to a JdbcPagingItemReader, and it has been a nightmare: job does not fail, writing process are ok, but data has mixed among the threads, and customer data were not right and coherent (customers have got services, addreses, etc. from others).

    So, why does it happen? How could I change to a multi-thread job?

    • Are the composite processor and writer right for multithread?
    • How could I make a custom thread-safe composite processor?
    • Maybe could it be the JDBC reader: Is there any thread-safe JDBC reader for multi-thread?

    I'm very locked and confused with this, so any help would be very appreciated. Thanks a lot.

    [EDIT - SOLVED]

    Well, the right and suitable fix to my issue is to design the job for multithread and thread-safe execution from the beggining. It's habitual to practice first with one-thread step execution, to understand and know Spring Batch concepts; but if you consider you are leaving this phase behind, considerations like immutable objects, thread-safe list, maps, etc... must raise.

    And the current fix in the current state of my issue has been the next I describe later. After test Martin's suggestions and taking into account Michael's guidelines, I have finally fix my issue as good as I could. The next steps aren't good practice, but I couldn't rebuild my job from the beggining:

    • Change itemReader to JdbcPagingItemReader with setState to false.
    • Change List by CopyOnWriteArrayList.
    • Change HashMap by ConcurrentHashMap.
    • In each delegated processor, get a new instance of every bean property (fortunately, there was only one injected bean) by passing the context (implements ApplicationContextAware) and getting a unique instance of the bean (configure every injected bean as scope="prototype").

    So, if the delegated bean was:

    <bean class="...MyProcessor">
    <property name="otherBean"  ref="otherBeanID" />
    

    Change to:

    <bean class="...MyProcessor">
    <property name="otherBean"  value="otherBeanID" />
    

    And, inside MyProcessor, get a single instance for otherBeanID from the context; otherBeanID must be configurated with scope="protoype".

    As I tell before, they're no good style, but it was my best option, and I can assert each thread has its own and different item instance and other bean instance.

    It proves that some classes has not been well designed for a right multithread execution.

    Martin, Michael, thanks for your support.

    I hope it helps to anyone.

    You have asked a lot in your question (in the future, please break this type of question up into multiple, more specific questions). However, item by item:

    Is JdbcCursorItemReader thread-safe?
    As the documentation states, it is not. The reason for this is that the JdbcCursorItemReader wraps a single ResultSet which is not thread safe.

    Are the composite processor and writer right for multithread?
    The CompositeItemProcessor provided by Spring Batch is considered thread safe as long as the delegate ItemProcessor implementations are thread safe as well. You provide no code in relation to your implementations or their configurations so I can't verify their thread safety. However, given the symptoms you are describing, my hunch is that there is some form of thread safety issues going on within your code.

    You also don't identify what ItemWriter implementations or their configurations you are using so there may be thread related issues there as well.

    If you update your question with more information about your implementations and configurations, we can provide more insight.

    How could I make a custom thread-safe composite processor?
    There are two things to consider when implementing any ItemProcessor:

    1. Make it thread safe: Following basic thread safety rules (read the book Java Concurrency In Practice for the bible on the topic) will allow you to scale your components by just adding a task executor.
    2. Make it idempotent: During skip/retry processing, items may be re-processed. By making your ItemProcessor implementation idempotent, this will prevent side effects from this multiple trips through a processor.

    Maybe could it be the JDBC reader: Is there any thread-safe JDBC reader for multi-thread?
    As you have noted, the JdbcPaginingItemReader is thread safe and noted as such in the documentation. When using multiple threads, each chunk is executed in it's own thread. If you've configured the page size to match the commit-interval, that means each page is processed in the same thread.

    Other options for scaling a single step
    While you went down the path of implementing a single, multi-threaded step, there may be better options. Spring Batch provides 5 core scaling options:

    1. Multithreaded step - As you are trying right now.
    2. Parallel Steps - Using Spring Batch's split functionality you can execute multiple steps in parallel. Given that you're working with composite ItemProcessor and composite ItemWriters in the same step, this may be something to explore (breaking your current composite scenarios into multiple, parallel steps).
    3. Async ItemProcessor/ItemWriters - This option allows you to execute the processor logic in a different thread. The processor spins the thread off and returns a Future to the AsyncItemWriter which will block until the Future returns to be written.
    4. Partitioning - This is the division of the data into blocks called partitions that are processed in parallel by child steps. Each partition is processed by an actual, independent step so using step scoped components can prevent thread safety issues (each step gets it's own instance). Partition processing can be preformed either locally via threads or remotely across multiple JVMs.
    5. Remote Chunking - This option farms the processor logic out to other JVM processes. It really should only be used if the ItemProcessor logic is the bottle neck in the flow.

    You can read about all of these options in the documentation for Spring Batch here: http://docs.spring.io/spring-batch/trunk/reference/html/scalability.html

    Thread safety is a complex problem. Just adding multiple threads to code that used to work in a single threaded environment will typically uncover issues in your code.

    Since I've read the book Java Concurrency in Practice I was wondering how I could use immutability to simplify synchronization problems between threads.

    I perfectly understand that an immutable object is thread-safe. Its state cannot change after initialization, so there cannot be "shared mutable states" at all. But immutable object have to be use properly to be considered useful in synchronization problems.

    Take for example this piece of code, that describes a bank wich owns many accounts and that exposes a method through which we can transfer money among accounts.

    public class Bank {
    
        public static final int NUMBER_OF_ACCOUNT = 100;
    
        private double[] accounts = new double[NUMBER_OF_ACCOUNT];
    
        private Lock lock;
        private Condition sufficientFunds;
    
        public Bank(double total) {
            double singleAmount = total / 100D;
            for (int i = 0; i < NUMBER_OF_ACCOUNT; i++) {
                accounts[i] = singleAmount;
            }
            lock = new ReentrantLock();
            sufficientFunds = lock.newCondition();
        }
    
        private double getAdditionalAmount(double amount) throws InterruptedException {
            Thread.sleep(1000);
            return amount * 0.04D;
        }
    
        public void transfer(int from, int to, double amount) {
            try {
                // Not synchronized operation
                double additionalAmount = getAdditionalAmount(amount);
                // Acquiring lock
                lock.lock();
                // Verifying condition
                while (amount + additionalAmount > accounts[from]) {
                    sufficientFunds.await();
                }
                // Transferring funds
                accounts[from] -= amount + additionalAmount;
                accounts[to] += amount + additionalAmount;
                // Signaling that something has changed
                sufficientFunds.signalAll();
            } catch (InterruptedException e) {
                e.printStackTrace();
            } finally {
                lock.unlock();
            }
       }   
    
       public double getTotal() {
           double total = 0.0D;
           lock.lock();
           try {
               for (int i = 0; i < NUMBER_OF_ACCOUNT; i++) {
                   total += accounts[i];
               }
           } finally {
               lock.unlock();
           } 
           return total;
        }
    
        public static void main(String[] args) {
            Bank bank = new Bank(100000D);
    
            for (int i = 0; i < 1000; i++) {
                new Thread(new TransferRunnable(bank)).start();
            }
        }
    }
    

    In the above example, that comes from the book Core Java Volume I, it is used synchronization through explicit locks. The code is clearly difficult to read and error prone.

    How can we use immutability to simplify the above code? I've tried to create an immutable Accounts class to hold the accounts value, giving to the Bank class a volatile instance of Accounts. However I've not reach my goal.

    Can anybody explain me if it is possible to simplify synchronization using immutability?

    ---EDIT---

    Probably I did not explain myself well. I know that an immutable object cannot change its state once it was created. And I know that for the rules implemented in the Java Memory Model (JSR-133), immutable objects are guaranteed to be seen fully constructed after their initialization (with some distingua).

    Then I've try to use these concepts to delete explicit synchronization from the Bank class. I developed this immutable Accounts class:

    class Accounts {
        private final List<Double> accounts;
    
        public Accounts(List<Double> accounts) {
            this.accounts = new CopyOnWriteArrayList<>(accounts);
        }
    
        public Accounts(Accounts accounts, int from, int to, double amount) {
            this(accounts.getList());
            this.accounts.set(from, -amount);
            this.accounts.set(to, amount);
        }
    
        public double get(int account) {
            return this.accounts.get(account);
        }
    
        private List<Double> getList() {
            return this.accounts;
        }
    }
    

    The accounts attribute of the Bank class have to be published using a volatile variable:

    private volatile Accounts accounts;
    

    Clearly, the transfer method of the Bank class will be changed accordingly:

    public void transfer(int from, int to, double amount) {
        this.accounts = new Accounts(this.accounts, from, to, amount);
    }
    

    Using an immutable object (Accounts) to store the state of a class (Bank) should be a publishing pattern, that is described at paragraph 3.4.2 of the book JCIP.

    However, there is still a race condition somewhere and I can't figure out where (and why!!!).

    Suppose I have a class like this:

    package com.spotonsystems.bulkadmin.cognosSDK.util.Logging;
    
    public class RecordLogging implements LittleLogging{
    
        private LinkedList <String> logs;
        private boolean startNew;
    
        public RecordLogging() {
            logs = new LinkedList<String>();
        }
    
        public void log(String log) {
            logHelper(log);
            startNew = true;
        }
    
        public void logPart(String log) {
            logHelper(log);
            startNew = false;
        }
    
        private void logHelper(String log){
            // DO STUFF
        }
    
        public LinkedList<String> getResults() {
            return logs;
        }
    
    }
    

    Now suppose that I need a thread safe version of this code. I need the tread safe version to implement LittleLogging. I want the thread safe copy to have the same behavior as this class except I would like it to be thread safe. Is it safe to do this:

    package com.spotonsystems.bulkadmin.cognosSDK.util.Logging;
    
    public class SyncRecordLogging extends RecordLogging {
    
        public SyncRecordLoging() {
            super();
        }
    
        public syncronized void log(String log) {
            super.log(log);
        }
    
        public syncronized void logPart(String log) {
            super.log(log);
        }
    
        public syncronized LinkedList<String> getResults() {
            return logs;
        }
    }
    

    Bonus Question: Where should I look for documentation about syncronization and threading

    You can use composition instead. Also note that getResults creates a copy of the list:

    public class SyncRecordLogging  implements LittleLogging{
    
        private final RecordLogging _log;
    
        public SyncRecordLogging() {
            _log = new RecordLogging();
        }
    
        public synchronized void log(String log) {
            _log.log(log);
        }
    
        public synchronized void logPart(String log) {
            _log.logPart(log);
        }
    
        public synchronized LinkedList<String> getResults() {
            // returning copy to avoid 'leaking' the enderlying reference
            return new LinkedList(_log.getResults());
        }
    }
    

    Best read: Java Concurrency In Practice

    The documentation of the tryLock method says that it is a non-blocking method
    which allows you to obtain/acquire the lock (if that's possible at the time of calling the method).

    But I wonder: how can you obtain a lock and still guarantee at the same time that
    your method (tryLock) is non-blocking?! Acquiring the lock implies that you're
    trying to access a guarded section of code so it should block (if you're not lucky
    i.e. you should block at least in certain scenarios). Could anyone explain the logic
    behind this? Purely from a logical standpoint: I don't quite understand how this can
    be done at all (guaranteeing that the method doesn't block). Unless they use another
    thread of course within the code of the tryLock itself...

    http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/Lock.html#tryLock%28%29

    Most implementations of these mechanisms use socalled CAS CPU instructions to do atomic actions based on a variable. CAS means Compare and Swap. These look at the value of a variable and if it is what you expect you change it. This provides a threadsafe (non blocking/locking) way to do comparison on data that is multithreaded.

    A CAS instruction does the following atomically:

    private int stored = 0;
    public int compareAndSwap(int expectedValue , int newValue)
    
       if(expectedValue == stored)
           stored = newValue;
    
       return stored;
    }
    

    These non blocking mechanisms generally just retry the above function until it succeeds (the returned value is the expected value). Because the retry loop is very short the chances of a thread interrupting on each iteration are tiny (or in practice the OS scheduler will even make it impossible).

    The actual java locks (Lock is just the interface they implement) are all much more complex because they offer extra features. But in essence the CAS mechanism is the base for most non-blocking threadsafe classes.

    If you are interested in the inner workings of locking, Java Concurrency in Practice is a great source. Starting gently with what Java concurrency can do and advancing in how it does it. (it is a great source even for non java programmers). Your question is handled in chapter 15.

    This code apparently runs well, but I read about pthreads and two threads can't read/write at the same time.

    class Sound{
        private:
            std::vector<int> waveColors;
            int progress;
        public:
            void analyze(){
                do{
                    //Perform FFT and update progress
                    waveColors.push_back(color)
                }while(progress < 100);
            }
            void getWaveColors(std::vector<int> *colors, int offset, int length){
                for(int i=offset;i<offset+length;i++){
                    colors.push_back(waveColors[i]);
                }
            }
            int getProgress(){
                return (progress);
            }
    }
    
    
    Sound *sound = new Sound();
    void *analyzeThread(void *arg){
        sound->analyze();
    }
    pthread_t analyzeThreadId;
    pthread_create (&analyzeThreadId, NULL, analyzeThread, 0);
    
    jintArray Java_package_getWaveColors(JNIEnv* env, jobject thiz, jint offset, jint limit){
        std::vector<int> colors;
        sound->getWaveColors(&colors, offset, limit);
    
        jintArray out = env->NewIntArray(colors.size());
    env->SetIntArrayRegion(out, 0, colors.size(), (jint *)&colors[0]);
        return out;
    }
    jint Java_package_getProgress(JNIEnv* env, jobject thiz){
        return (jint)sound->getProgress();
    }
    

    What is the correct way (semaphores, mutual exclusions?) in this class for keep running the UI update loop?

    Thanks in advance

    Based on the guidance on the front page of the Android NDK, I'd suggest writing your application in Java, and then re-writing a very small performance-intensive part of it in C++ - not any of the the UI parts.

    The C++ part might be purely the FFT computation itself. Structure it so you can carry out a limited but significant "chunk" of the work in a single step, and have the chunk-size controlled by a variable so you can try adjusting it later.

    Finally, when using a background worker thread in this way, create a thread-safe queue to use for communication purposes. The worker can push chunks of results on to the back of the queue as it completes them, and the foreground thread can pop those completed chunks from the front of the queue each time it refreshes the UI. Of course, you need to ensure that you don't modify the chunk objects once they are "published" to the queue.

    Reference for thread-safe queues in Java: http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/package-summary.html

    Ideally you should read this: http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601/

    Why do you have to specify, which object has locked a synchronized block of code?

    You don't have to specify which object has locked a synchronized method as it is always locked by 'this' (I believe).

    I have two questions:

    • Why can't you block a none static method with an object other than 'this' ?
    • Why do you have to specify the object that has blocked synchronized code?

    I have read chapter nine of SCJP for Java 6, but I am still not clear on this.

    I realize it is probably a basic question, but I am new to Threading.

    It is not recommended to lock each method with this as it reduces the concurrency in most cases. So it is recommended to use Lock Stripping in which only the specific part of the code that needs to be protected is kept in synchronized block.

    It is a practice that is explained well in Java Concurrency in Practice. But note this book is useful only when you have some basic experience with threading.

    Some nuggets to keep in mind:

    • Do not overuse synchronization
    • use method level synchronization only when the whole method needs to be protected
    • Use different locks to protect two unrelated entities, which will increase the chances of concurrency. or else for reading or writing two unrelated entities threads will block on same lock.

      public void incrementCounter1(){
           synchronized(lockForCounter1){
               counter1++;
           }
      }  
      
      public void incrementCounter2(){
           synchronized(lockForCounter2){
               counter2++;
           } 
      }
      

    Possible Duplicate:
    Difference between volatile and synchronized in JAVA (j2me)

    I am a bit confused with the 2 java keywords synchronized and volatile.

    To what i understand, since java is a multi-threaded language, and by using the keyword synchronized will force it to be executed in 1 thread. Am i correct ?

    And volatile also does the same thing ?

    Java multi-threading involves two problems, ensuring that multiple operations can be done consistently, without mixing actions by different threads, and making a change in a variable's value available to threads other than the on doing the change.

    In reality, a variable does not naturally exist at a single location in the hardware. There may be copies in the internal state of different threads, or in different hardware caches. Simply assigning to a variable automatically changes its value from the point of view of the thread doing the assignment.

    If the variable is marked "volatile" other threads will get the changed value.

    "synchronized" also ensures changes become visible. Specifically, any change done in one thread before the end of a synchronized block will be visible to reads done by another thread in a subsequent block synchronized on the same object.

    In addition, blocks that are synchronized on the same object are forced to run sequentially, not in parallel. That allows one to do things like adding one to a variable, knowing that its value will not change between reading the old value and writing the new one. It also allows consistent changes to multiple variables.

    The best way I know to learn what is needed to write solid concurrent code in Java is to read Java Concurrency in Practice

    Basically this code has two threads created in two classes, and they are called from the third class. Each thread has a loop, and it sleeps after each iteration.

    (code is in the end)

    The output is:

    CHECK 0 CHECK
    CHECK 1 CHECK
    run one
    in thread1 
    CHECK 2 CHECK
    run two
    in thread2
    

    1) I am not getting any idea why it works this way. I mean it is okay that CHECK 0 CHECK should be printed first. But why does CHECK 1 CHECK get printed before Thread1 (whereas it comes after Thread1 is called in the code) and same for CHECK 2 CHECK and Thread2?

    2) If i replace CHECK 2 CHECK with System.exit(0), as in the case above, where printing CHECK 2 CHECK, which is next to Thread2, takes place before running Thread2, Why is System.exit(0) happening after running Thread2 in this case?

    Output for second case:

    CHECK 0 CHECK
    CHECK 1 CHECK
    run one
    in thread1 
    run two
    in thread2
    

    Please tell why this is happening? Why are the threads and code in method, getting mixed up this way? I think i don't have any idea about how threads are managed by java. I tried searching a lot, but could not find anything that i could understand.

    Code:

    public class Thread1 implements Runnable 
    {
    
        public Thread1()
        {
            new Thread(this).start();
        }
    
        public void run() 
        {
            // TODO Auto-generated method stub
            System.out.println("run one");
            try
            {
                for(int i = 0; i < 5;i++)
                {
                    System.out.println("in thread1 ");
                    Thread.sleep(1000);
                }
            }
            catch(Exception e)
            {
                //e.printStackTrace();
            }
        }
    
    }
    
    public class Thread2 implements Runnable 
    {
    
        public Thread2()
        {
            new Thread(this).start();
        }
    
        public void run() 
        {
            // TODO Auto-generated method stub
            System.out.println("run two");
            try
            {
                for(int i=0;i<5;i++)
                {
                    System.out.println("in thread2 ");
                    Thread.sleep(1000);
                }
            }
            catch(Exception e)
            {
                //e.printStackTrace();
            }
        }
    }
    
    public class Threadjava
    {
        public static void main(String[] str)
        {
            System.out.println("CHECK 0 CHECK");
            new Thread1();
            System.out.println("CHECK 1 CHECK");
            new Thread2();
            System.out.println("CHECK 2 CHECK");
            //The above is deleted in the second case
            System.exit(0);
            System.out.println("CHECK 3 CHECK");
        }
    }
    

    Well, this is a common misconception, that java programs are single threaded by nature, because they are not. When you start a java program it's being executed inside a Java Virtual Machine, which starts several other threads to execute your code. Check this nice blog:

    http://blog.jamesdbloom.com/JVMInternals.html#jvm_system_threads

    In your case you most important is, that you start a main thread, which executes a main method. From there you start two separate threads Thread1 and Thread2, which are being scheduled to be executed, but you don't know when they will be picked up by the OS scheduler to be actually executed. It's not deterministic for many reasons:

    • you don't know what algorithm scheduler is using to pick up threads to be executed,
    • you don't know how many cores your processors have, your threads might run in parallel or serially
    • Just In Time compiler might rearrange and optimise your code,
    • CPU might rearrange reads and writes to IO to optimise the execution of your code,
    • you might have bugs in your code that lead to data races, race conditions, starvations etc.

    Java concurrency is a hard topic and the blog entry that I've sent you is a good place to start, go with it. For serious reading go here http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601.

    Good luck.

    Consider a distributed bank application, wherein distributed agent machines modify the value of a global variable : say "balance"

    So, the agent's requests are queued. A request is of the form wherein value is added to the global variable on behalf of the particular agent. So,the code for the agent is of the form :

      agent
        {
         look_queue(); // take a look at the leftmost request on queue without dequeuing
    
         lock_global_variable(balance,agent_machine_id);    
         /////////////////////  **POINT A**
         modify(balance,value);
         unlock_global_variable(balance,agent_machine_id);  
         /////////////////// **POINT B**
         dequeue();      //  once transaction is complete, request can be dequeued
        }
    

    Now, if an agent's code crashes at POINT B, then obviously the request should not be processed again, otherwise the variable will be modified twice for the same request. To avoid this, we can make the code atomic, thus :

    agent
    {
     look_queue(); // take a look at the leftmost request on queue without dequeuing
    
     *atomic*
     {   
      lock_global_variable(balance,agent_machine_id); 
      modify(balance,value);
      unlock_global_variable(balance,agent_machine_id);
      dequeue();      //  once transaction is complete, request can be dequeued
     }
    }       
    

    I am looking for answers to these questions :

    1. How to identify points in code which need to be executed atomically 'automatically' ?
    2. IF the code crashes during executing, how much will "logging the transaction and variable values" help ? Are there other approaches for solving the problem of crashed agents ?
    3. Again,logging is not scalable to big applications with large number of variables. What can we in those case - instead of restarting execution from scratch ?
    4. In general,how can identify such atomic blocks in case of agents that work together. If one agent fails, others have to wait for it to restart ? How can software testing help us in identifying potential cases, wherein if an agent crashes, an inconsistent program state is observed.
    5. How to make the atomic blocks more fine-grained, to reduce performance bottlenecks ?

    Q> How to identify points in code which need to be executed atomically 'automatically' ?
    A> Any time, when there's anything stateful shared across different contexts (not necessarily all parties need to be mutators, enough to have at least one). In your case, there's balance that is shared between different agents.

    Q> IF the code crashes during executing, how much will "logging the transaction and variable values" help ? Are there other approaches for solving the problem of crashed agents ?
    A> It can help, but it has high costs attached. You need to rollback X entries, replay the scenario, etc. Better approach is to either make it all-transactional or have effective automatic rollback scenario.

    Q> Again, logging is not scalable to big applications with large number of variables. What can we in those case - instead of restarting execution from scratch ?
    A> In some cases you can relax consistency. For example, CopyOnWriteArrayList does a concurrent write-behind and switches data on for new readers after when it becomes available. If write fails, it can safely discard that data. There's also compare and swap. Also see the link for the previous question.

    Q> In general,how can identify such atomic blocks in case of agents that work together.
    A> See your first question.

    Q> If one agent fails, others have to wait for it to restart ?
    A> Most of the policies/APIs define maximum timeouts for critical section execution, otherwise risking the system to end up in a perpetual deadlock.

    Q> How can software testing help us in identifying potential cases, wherein if an agent crashes, an inconsistent program state is observed.
    A> It can to a fair degree. However testing concurrent code requires as much skills as to write the code itself, if not more.

    Q> How to make the atomic blocks more fine-grained, to reduce performance bottlenecks?
    A> You have answered the question yourself :) If one atomic operation needs to modify 10 different shared state variables, there's nothing much you can do apart from trying to push the external contract down so it needs to modify more. This is pretty much the reason why databases are not as scalable as NoSQL stores - they might need to modify depending foreign keys, execute triggers, etc. Or try to promote immutability.

    If you were Java programmer, I would definitely recommend reading this book. I'm sure there are good counterparts for other languages, too.

    Hey guys. I am trying to write a file transfer application in java and so far it's been ok: i start the server and the client and then transfer the file. I'm having trouble connecting multiple clients to the same server. I googled it and found out that my server side should run in threads. How can i do that with my application? Thanks.

    Server:

    package filesharing;
    import java.io.*;
    import java.net.*;
    
    public class Server
    {
        public static void main(String args[])throws Exception
        {
            System.out.println("Server pornit...");
    
            /* Asteapta pe portul  1412 */
    
            ServerSocket server = new ServerSocket(1412);
    
            /* Accepta socketul */
    
            Socket sk = server.accept();
    
            System.out.println("Client acceptat de catre server pe portul: "+server.getLocalPort());
            InputStream input = sk.getInputStream();
            BufferedReader inReader = new BufferedReader(new InputStreamReader(sk.getInputStream()));
            BufferedWriter outReader = new BufferedWriter(new OutputStreamWriter(sk.getOutputStream()));
    
            /* Citeste calea fisierului */
            String filename = inReader.readLine();
    
            if ( !filename.equals("") ){
    
                /* Trimite status READY catre client */
    
                outReader.write("READY\n");
                outReader.flush();
            }
    
            /* Creaza fila noua in directorul tmp */
            FileOutputStream wr = new FileOutputStream(new File("C://tmp/" + filename));
    
            byte[] buffer = new byte[sk.getReceiveBufferSize()];
    
            int bytesReceived = 0;
    
            while((bytesReceived = input.read(buffer))>0)
            {
                /* Scrie in fila */
               wr.write(buffer,0,bytesReceived);
            }
        }
    }
    

    Client:

    package filesharing;
    
    import javax.swing.*;
    import java.awt.*;
    import java.awt.event.*;
    import java.net.*;
    import java.io.*;
    
    public class Client extends JFrame implements ActionListener {
    
        private JTextField txtFile;
    
        public static void main(String args[]){
    
            /* Creare pannel client */
    
            Client clientForm = new Client();
            clientForm.Display();
        }
    
        public void Display(){
    
            JFrame frame = new JFrame();
            frame.setTitle("Client");
    
            FlowLayout layout = new FlowLayout();
            layout.setAlignment(FlowLayout.LEFT);
    
            JLabel lblFile = new JLabel("Fisier:");
    
            txtFile = new JTextField();
            txtFile.setPreferredSize(new Dimension(150,30));
    
            JButton btnTransfer = new JButton("Transfer");
            btnTransfer.addActionListener(this);
    
            JPanel mainPanel = new JPanel();
            mainPanel.setLayout(layout);
            mainPanel.add(lblFile);
            mainPanel.add(txtFile);
            mainPanel.add(btnTransfer);
    
            frame.getContentPane().add(mainPanel);
            frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
            frame.pack();
            frame.setVisible(true);
    
        }
    
        public void actionPerformed(ActionEvent e) {
    
            /* Casuta File Open Dialog pentru selectarea fisierului */
    
            JFileChooser fileDlg = new JFileChooser();
            fileDlg.showOpenDialog(this);
            String filename = fileDlg.getSelectedFile().getAbsolutePath();
            txtFile.setText(filename);
    
            try{
    
                /* Incearca conectarea la serverul localhost pe portul 1412 */
    
                Socket sk = new Socket("localhost", 1412);
                OutputStream output = sk.getOutputStream();
    
                /* Trimite numele fisierului la server */
    
                OutputStreamWriter outputStream = new OutputStreamWriter(sk.getOutputStream());
                outputStream.write(fileDlg.getSelectedFile().getName() + "\n");
                outputStream.flush();
    
                /* Asteapta raspunsul de la server */
    
                BufferedReader inReader = new BufferedReader(new InputStreamReader(sk.getInputStream()));
    
                String serverStatus = inReader.readLine(); // Citeste prima linie
    
                /* Daca serverul e READY trimite fisierul */
    
                if ( serverStatus.equals("READY") ){
    
                    FileInputStream file = new FileInputStream(filename);
    
                    byte[] buffer = new byte[sk.getSendBufferSize()];
    
                    int bytesRead = 0;
    
                    while((bytesRead = file.read(buffer))>0)
                    {
                        output.write(buffer,0,bytesRead);
                    }
    
                    output.close();
                    file.close();
                    sk.close();
    
                    JOptionPane.showMessageDialog(this, "Transfer complet");
    
                }
            }
            catch (Exception ex){
                /* Catch pentru eventuale erori */
                JOptionPane.showMessageDialog(this, ex.getMessage());
            }
        }
    }
    

    To define and start a thread you need an implementation of the class Runnable that is passed to a Thread instance on which you call start.

    This question is very similar and will provide you a place to start. One answer points to a socket tutorial that shows how to use multiple clients. If you haven't read the Socket tutorials, you definitely should.

    But don't stop at knowing just the basics of threading or you'll run into problems. Concurrency is a hard problem. You will want to read up on the great world of Java concurrency.

    Ideally you will be inspired enough to read Java Concurrency in Practice, an amazing reference on concurrency in Java.

    I am planning to attend a one week course on this subject. I am primarily involved in Java projects and have decent knowledge of C and C++ too. And, I am interested in learning more on concurrent programming and would like to get feedback on this course. Has someone read the book or found these concepts relevant in contemporary programming?

    More information on the course: http://www.amazon.com/Art-Multiprocessor-Programming-Maurice-Herlihy/dp/0123705916/

    I would definitely, suggest you to go with this. But I would like to add another really important resource, specific to java - as you labeled the question 'java' - which is Java Concurrency in Practice.

    I'd like a little help understanding how setting an object to null works in java. I have a situation where, seemingly, at first glance it appears that an object that is set to null, is suddenly not null, but obviously this can't be the case.

    I have a class in which I create an object. This object is a scene. This is an Open GL ES 2.0 project, so this scene's render() and updateLogic() methods are called from onDrawFrame (this is controlled via a Scene Manager so we can easily switch scenes).

    So, I might have something like this (code cut down for the purpose of the question):

    public class MyGLRenderer implements GLSurfaceView.Renderer{
    
        MyScene myScene;
        SomeOtherScene someOtherScene;
    
        public void createScenes(){
            myScene = new MyScene(this);
            someOtherScene = new SomeOtherScene(this);
            SceneManager.getInstance().setCurrentScene(myScene);
        }
    
        public void cleanUp(){
            myScene = null;
            Log.v("tag","myScene (from MyGLRenderer) is: "+myScene);
            SceneManager.getInstance().setCurrentScene(someOtherScene);   //Scene changed but this won't take effect until the next 'tick'   
        } 
    
        @Override
        public void onDrawFrame(GL10 gl) {
            SceneManager.getInstance().getCurrentScene().updateLogic();
            SceneManager.getInstance().getCurrentScene().render();
        }
    
    }
    

    In the above situation, processing is turned over to myScene which would look something like this:

    public class MyScene implements Scene{
    
        MyGLRenderer renderer;
    
        public myScene(MyGLRenderer renderer){     
            this.renderer = renderer;
        }
    
        @Override
        public void render(){
            //Render something here
        }
    
        @Override
        public void updateLogic(){
            doSomething();           
            //The condition here could be anything - maybe the user taps the sceen and a flag is set in onTouchEvent for example
            if (someConditionIsMet){
                renderer.cleanup();
            }            
             Log.v("tag","myScene (from within myScene) is: "+this);
        }
    }
    

    So, when I set the scene using my scene manager, processing is turned over to that scene and it's updateLogic and render methods get called from onDrawFrame continuously.

    When I ran my code, I was suprised it didn't crash with a NullpointerException. The logs were like this:

    myScene (from within myScene) is: com.program.name.MyScene@26354632
    myScene (from within myScene) is: com.program.name.MyScene@26354632
    myScene (from within myScene) is: com.program.name.MyScene@26354632
    myScene (from within myScene) is: com.program.name.MyScene@26354632
    myScene (from within myScene) is: com.program.name.MyScene@26354632
    myScene (from within myScene) is: com.program.name.MyScene@26354632
    myScene (from within myScene) is: com.program.name.MyScene@26354632
    myScene (from within myScene) is: com.program.name.MyScene@26354632
    myScene (from MyGLRenderer) is: null
    myScene (from within myScene) is: com.program.name.MyScene@26354632
    

    As you can see, 'myScene' is valid up until the cleanUp() method is called and sets it to null. But the code then returns to myScene to finish off, where it's still valid (not null).

    I'd really like to understand how thing works in Java - why does it seem to be null one minute (or from one place) and then not (from a different place)?

    Looks like you have run into a thread safety bug.

    Other threads can see stale values of a variable unless you "safely publish" the change of value. (You have one CPU changing a value in its cache line, but another CPU is still seeing stale cache data - you need to force the cache to write up to main memory but this is expensive so Java does not do this until it is told to).

    There are many ways to safely publish a value depending on your exact requirements. Looking at your code it seems that all you need to do is declare the myScene field to be volatile. It probably should be private too. So try:

    private volatile Scene myScene;
    

    If you want to properly understand thread safety in Java, then I highly recommend "the Train Book": http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601

    I gone through the article "http://www.ibm.com/developerworks/java/library/j-jtp10264/".They mentioned that "The Lock framework is a compatible replacement for synchronisation". I understood that by using Reentrant locks we can hold the lock across the methods, wait for the lock for certain period of time (It is not possible using synchronised block (or) methods). My doubt is, is it possible to replace the application with synchronisation mechanism with Reentrant locks?

    For example, I want to implement a thread safe stack data structure, where all the push, pop, getTop methods are synchronised, so in multi threaded environment, only one thread can able to access one synchronised method at a time (If one thread is using push method, no other threads can able to access push, pop, getTop (or) any other synchronised methods of Stack class). Is it possible to implement same thread safe stack data structure using Reentrant lock? If possible, please provide an example to understand this.

    Brian Goetz discusses this in "Java Concurrency in Practice" in chapter 13.4:

    ReentrantLock is an advanced tool for situations where intrinsic locking is not practical. Use it if you need its advanced features: timed, polled, or interruptible lock acquisition, fair queueing, or non-block-structured locking. Otherwise, prefer synchronized.

    I absolutely agree because IMHO this:

    synchronized (lock) {
        // ...
    }
    

    Is way more readable and less error prone than this:

    try {
        lock.lock();
        // ...
    } finally {
        lock.unlock();
    }
    

    Long story short: from a technical point of view, yes, you could replace synchronized with ReentrantLock, but I wouldn't do it per se.

    Also checkout these questions:

    I have a class "A" with method "calculate()". Class A is of type singleton(Scope=Singleton).

    public class A{ 
    
    public void calculate(){
       //perform some calculation and update DB
     }
    
    }
    

    Now, I have a program that creates 20 thread. All threads need to access the method "calculate()". I have multicore system. So I want the parallel processing of the threads.

    In the above scenario, can i get performance? Can all threads access the method calculate at same instance of time?

    Or, Since the class A is singleton so, the threads needs to be blocked waiting.

    I have found similar questions in the web/Stackoverflow. But I cannot get clear answer. Would you please help me?

    Statements like "singletons need synchronization" or "singletons don't need synchronization" are overly simplistic, I'm afraid. No conclusions can be drawn only from the fact that you're dealing with the singleton pattern.

    What really matters for purposes of multithreading is what is shared. If there are data that are shared by all threads performing the calculation, then you will probably need to synchronize that access. If there are critical sections of code than cannot run simultaneously between threads, then you will need to synchronize that.

    The good news is that often times it will not be necessary to synchronize everything in the entire calculation. You might gain significant performance improvements from your multi-core system despite needing to synchronize part of the operation.

    The bad news is that these things are very complex. Sorry. One possible reference:

    http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601/ref=sr_1_1?ie=UTF8&qid=1370838949&sr=8-1&keywords=java+concurrency+in+practice

    i have an ImageView in which the picture switches every 5s, i am trying to add a pause and

    resume button that can stop and restart the action. i am using a Handler, Runnable, and

    postDelay() for image switch, and i put the code on onResume. i am thinking about using

    wait and notify for the pause and resume, but that would mean creating an extra thread. so

    far for the thread, i have this:

    class RecipeDisplayThread extends Thread { boolean pleaseWait = false;

        // This method is called when the thread runs
        public void run() {
            while (true) {
                // Do work
    
                // Check if should wait
                synchronized (this) {
                    while (pleaseWait) {
                        try {
                            wait();
                        } catch (Exception e) {
                        }
                    }
                }
    
                // Do work
            }
        }
    
    }   
    

    and in the main activity's onCreate():

            Button pauseButton = (Button) findViewById(R.id.pause);
    
            pauseButton.setOnClickListener(new View.OnClickListener() 
            {
                public void onClick(View view) 
                {
                    while (true) {
    
                    synchronized (thread) 
                    {
                        thread.pleaseWait = true;
                        }
                    }
    
                }
            });
    
            Button resumeButton = (Button) findViewById(R.id.resume);
    
            resumeButton.setOnClickListener(new View.OnClickListener() 
            {
                public void onClick(View view) 
                {
                    while (true) {
    
                    // Resume the thread
                    synchronized (thread) 
                    {
                        thread.pleaseWait = false;
                        thread.notify();
                    }
                    }
    
                }
            });
    

    the pause button seems to work, but then after that i can't press any other button, such as

    the resume button.

    thanks.

    i am using a Handler, Runnable, and postDelay() for image switch

    Why? Why not use postDelayed() and get rid of the Thread and Handler?

      void doTheImageUpdate() {
        if (areWeStillRunning) {
          myImageView.setImageResource(R.drawable.whatever);
          myImageView.postDelayed(updater, 5000);
        }
      }
    
      Runnable updater=new Runnable() {
        public void run() {
          doTheImageUpdate();
        }
      };
    

    When you want to start updating, set areWeStillRunning to true and call doTheImageUpdate(). When you want to stop updating, set areWeStillRunning to false. You'll need to work out the edge case of where the user presses pause and resume within 5 seconds, to prevent doubling things up, but I leave that as an exercise for the reader.

    If you really want to use a background thread, you will want to learn more about how to use background threads. For example, while(true) {} without any form of exit will never work. There are some good books on the subject, such as this one.

    I have a single thread pool for task execution. As far as I know, continue working after OutOfMemoryError is occured is very dangerous. We should terminate our application if this happens. So, consider the following:

    ExecutorService es = Executors.newSingleThreadExecutor();
    es.submit(new Runnable() {
        @Override
        public void run() {
            throw new OutOfMemoryError();
        }
    });
    es.shutdown();
    es.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS);
    System.out.println("After throwing OutOfMemoryError");
    

    In this code, we have the task throws OutOfMemoryError. But even after throwing it continues working and prints After throwing OutOfMemoryError.

    Is it safe? I mean, we may end up with data corruption... Should we be prepared to this sort of scenarios and design tasks to terminate the application if Error is thrown?

    There are two threads in the given example -- the main thread that starts the program and a thread for executing the specified tasks. All threads are allocated their own, independent from each other, stacks. However, all threads use the same memory heap. This is why the OutOfMemoryError effects the whole program, not just a single thread.

    Generally speaking, upon termination (successfully or otherwise), the task executing thread does not effect execution flow of any other thread (unless this is what it was designed for doing). That is why, the main thread in the provided example, keeps running even though the task thread got terminated.

    I would highly recommend studying the Java Concurrency in Practice book to get better overall undestanding of the Java concurrency and parallelism.

    I have a Spring batch job running 4 times a day.Once the job is started, it checks the status of the previous job. If previous job status is "started", then the job is aborted. I have a query to check that. The problem is that, if one job fails checking the previous job status, its status will be "failed" and the next job will start processing, so that two instances will run in parallel. So we have to manually stop one.This forces us to consistently monitor the job. So, I have also tried by changing the query to check for previous 5 job runs. That is fine. But is there any other way using JVM or some other techniques that we can meet this criteria??

    Please suggest..!

    If no 2 jobs can run at the same time, it is probably because there is a resource that you want to protect. Locking mechanisms are best suited for this. Read Java Concurrency In Practice for more info on that. If you don't have quick access to this excellent book, you can start at http://docs.oracle.com/javase/tutorial/essential/concurrency/

    I have been trying to wrap my head around callbacks and have been struggling to grasp the concept. The following code is an example that I found here

    starting from first to last I understand the flow to be such:

    • CallMe is instantiated, thus calling the constructor of said class
    • The variable en is set, subsequently instantiating the EventNotifier class and calling it's constructor which is passed a reference to the object CallMe
    • The variable ie is set to the object CallMe which was passed into the constructor
    • The variable somethinghappened is set to false (I would assume some conditional statement would be used to determine whether or not to set the value otherwise)
    • Ummm... done?

    I do not understand this code. How does doWork get called? How does this signify an event? Why would one not simply call interestingevent from the constructor of callme .... For that matter why not just call dowork in place of whatever would change the value of somethinghappened?

    Try as I might I cannot seem to grasp the idea. I understand that callbacks are used primarily to signify an event has occurred such as a mouse or button click but how does it make the connection between the event occurring and the methods being called? Should there not be a loop that checks for changes, and thus triggers the event?

    Can someone please provide a (not over-simplified) explanation of callbacks in java and help clarify how something like this could be useful?

    public interface InterestingEvent
    {
        public void interestingEvent ();
    }
    
    public class EventNotifier
    {
        private InterestingEvent ie;
        private boolean somethingHappened; 
        public EventNotifier (InterestingEvent event)
        {
            ie = event; 
            somethingHappened = false;
        } 
    
        public void doWork ()
        {
            if (somethingHappened)
            {
                ie.interestingEvent ();
            }
        } 
    }
    
    public class CallMe implements InterestingEvent
    {
        private EventNotifier en; 
        public CallMe ()
        {
            en = new EventNotifier (this);
        } 
    
        public void interestingEvent ()
        {
            // Wow!  Something really interesting must have occurred!
            // Do something...
        } 
    }
    

    EDIT: please see the comments in the approved answer... ---this--- link was very helpful for me =)

    There is no main method or static blocks. Nothing is actually run from the code you posted; hence, doWork() is never called. I read the article and looked at the code, and it appears to be incomplete, or perhaps some code is left out because the author felt that it didn't need to be explained.

    Here's the gist:

    We have an interface InterestingEvent, a class EventNotifier, and another class CallMe, which implements InterestingEvent.

    EventNotifier takes an InterestingEvent in its constructor, and sets somethingHappened to false.

    The constructor for CallMe initializes its EventNotifier instance member by passing the EventNotifier constructor a reference to the CallMe object, itself.

    The following is not in the code, but if we detect that some particular action takes place, we set somethingHappened = true. So after that, if doWork() is called for an EventNotifier, interestingEvent() will be called on that EventNotifier's InterestingEvent ie. We can do this, since CallMe implements InterestingEvent.

    NB: This article was from 1996 and much has changed since then. You mentioned how to detect mouse click events, but this is different. The point of the article, I assume, was to show how you can use objects in conjunction with interfaces and booleans to see if something occurred.

    To actually detect a mouse click, take a look at this tutorial. Here's another tutorial on Writing Event Listeners. Finally, since you asked about threading in a comment, here's a great book: Java Concurrency in Practice.

    I have java.util.List declared as follows:

    private static List<String> extensions = null;
    

    It is populated by single thread always.

    But multiple threads can call simultaneously method contains(E e) on extensions.

    Is it threadsafe ?

    List is populated by single thread at startup and cannot be modified afterwards. Is now contains threadsafe?

    An object used in that way is called "effectively immutable"---the program is allowed to change the object, but it doesn't. The book, Java Concurrency in Practice by Brian Goetz has a section that deals specifically with safe publication of effectively immutable objects. http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601

    The short answer (assuming that I am remembering it correctly) is that if you populate the list inside a constructor, and if no other thread can access the list before the constructor returns, then the list is safely published. I am assuming, of course, that the items you put in the list are also effectively immutable.

    "Safe publication" means that other threads will be guaranteed to see the list in its intended, final state. If the list were not safely published, then threads running on different processors could see different versions of the list (potentially including some version where the list was in an inconsistent state that could crash your program when you tried to access it.)

    I have just started Android Development, I want to make thread in my application which get the current location after every thirty seconds. Kindly give me some hints or any tutorial link which you think is useful for this problem.

    This is a good place to start. Note that if you are new to Android development you will find a lot of good resources at the Android website. Start there and maybe grab a good book on threads in Java, this one is very good book for that.

    I have lots of legacy code, which to a large extent consists of classes with following structure:

    public interface MyFunctionalBlock
    {
        // Setters for the inputs
        void setInput1(final int aInput1);
        void setInput2(final Object aInput2);
    
        // Inside the method run inputs are converted into results
        void run();
    
        // If this building block needs functionality from some other building blocks,
        // it gets a reference to them from the Google Guice injector.
        void setInjector(final Injector aInjector);
    
        // Getters for the results
        long getResult1();
        Object getResult2();
        Map<String,String> getResult3();
    }
    
    public class MyFunctionalBlockFactory implements Factory<MyFunctionalBlock>
    {
        public MyFunctionalBlock create()
        {
            return new DefaultMyFunctionalBlock();
        }
    }
    
    class DefaultMyFunctionalBlock implements MyFunctionalBlock
    {
        private int input1;
        private Object input2;
        private long result1;
        private long result2;
        private Map<String,String> result3;
        private Injector injector;
    
        @Override
        public void run()
        {
            // Here the calculations are performed.
    
            // If this functional block needs another one, it gets a reference to it using the injector.
            // AnotherFunctionalBlock is the public interface. Implementations of the interface are 
            // intentionally hidden using injector and package-private declaration.
            final AnotherFunctionalBlock fb = injector.getInstance(AnotherFunctionalBlock.class);
    
            // First, we set the inputs
    
            fb.setInput1(...);
            fb.setInput2(...);
    
            [...]
    
            fb.setInputN(...);
    
            // Now we run the calculation
    
            fb.run();
    
            // Now we can use the results
            fb.getResult1();
            fb.getResult2();
    
            [...]
    
            fb.getResultN();
        }
    
        // Implementation of getters and setters omitted
    }
    

    Basically, the entire application consists of such building blocks, which use each other.

    Up to now, the application was used in a single-threaded mode. Now I need to modify it such that

    1. the building blocks are thread safe and
    2. the changes to the code, which uses them are minimal (ideally, I would change only the inner workings of the building blocks without touching the public interfaces and calling routines).

    How can I do this?

    I thought about putting the code from setting the first input to reading the last result into synchronized block (something like the code example below), but it would require rewriting the entire application.

    final AnotherFunctionalBlock fb = injector.getInstance(AnotherFunctionalBlock.class);
    
    synchronized(fb)
    {
        fb.setInput1(...);
        fb.setInput2(...);
    
        [...]
    
        fb.setInputN(...);
    
        fb.run();
        fb.getResult1();
        fb.getResult2();
    
        [...]
    
        fb.getResultN();        
    }
    

    Update 1 (09.06.2013 21:57 MSK): A potentially important note - the concurrency stems from the fact that there are N web services, which receive a request, then use the old code to make calculations based on that request and return the results to the web service client.

    A potential solution would be to add some sort of queue between web services and the old code.

    Update 2:

    I thought about how to make my code thread-safe with minimum possible effort and found following solution (currently, I don't care about performance).

    There are several web service classes, which all have a backend property and access it concurrently.

    public class WebService1
    {
    
      private Backend backend;
    
      public Response processRequest(SomeRequest1 request)
      {
        return wrapResultIntoResponse(backend.doSomeThreadUnsafeStuff1(request.getParameter1(), request.getParameter2()));
      }
    }
    
    public class WebService2
    { 
      private Backend backend;
    
      public Response processRequest(SomeRequest2 request)
      { 
        return wrapResultIntoResponse(backend.doSomeThreadUnsafeStuff2(request.getParameter1(), request.getParameter2(), request.getParameter3()));
      }
    }
    

    All calls to the non-threadsafe code go via the Backend class (all web services reference one and the same Backend instance).

    If I ensure that the backend processes one request after another (and never processes two requests simultaneously), I can achieve the desired result without re-writing the entire application.

    Here's my implementation of Backend class:

    public class Backend
    { 
        private synchronized boolean busy = false;
    
        public Object doSomeThreadUnsafeStuff1(Long aParameter1, String aParameter2)
        {
            waitUntilIdle();
    
            synchronized (this)
            {
    
                busy=true;
    
                // Here comes the non-thread safe stuff 1
    
                busy=false;
    
                notifyAll();
            }
        }
    
        public Object doSomeThreadUnsafeStuff2(Long aParameter1, String aParameter2, Map<String,String> aParameter3)
        {
            waitUntilIdle();
    
            synchronized (this)
            {
    
            busy=true;
    
            // Here comes the non-thread safe stuff 2
    
            busy=false;
            notifyAll();
            }
        }
        private void waitUntilIdle()
        {
          while (busy)
          {
            wait();
          }
        } 
    }
    

    Can this solution work?

    It's unclear what you're trying to accomplish beyond "making it multi-threaded". Concurrency in Java is a very complex subject, and you're not going to find a single, step-by-step answer for how to convert an entire application from single- to multi-threaded. If you do, I'd mistrust that answer thoroughly. I suggest you pick up "Java Concurrency in Practice", the de facto reference for such things. That's how you'll learn what you need to know in order to tackle this problem.

    I have read the Java Concurrency in Practice on page 146, and I have coded the:

    class RethroableTask implements Runnable{
        private static final ScheduledExecutorService cancelExec =
                Executors.newScheduledThreadPool(1);
       private Throwable t;
       public void run(){
           try{
                while(true){}
          }catch(Throwable t){
                this.t = t;
           }
       }
    
      public static void main(String[] args){
              RethroableTask task = new RethrowableTask();
              final Thread taskThread = new Thread(task);
              taskThread.start();
              cancelExec.schedule(new Runnable(){
                  public void run(){
                    taskThread.interrupt();//i want taskThread can catch interruptedException
          }
         },1,TimeUnit.SECONDS);
    
        }
    }
    

    I want taskThread to catch InterruptedException as Throwable, and really the taskThread isInterrupted is true,but taskThread never catches it. Why?

    I substitute while(true){} with

      try{
         Thread.currentThread().sleep(1000);//a blocking method
         }catch(InterruptedException e){
          System.out.println("interruptedException");
         Thread.currentThread().interrupt();
      }
    

    it come in catch

    An InterruptedException is only thrown when a thread is waiting on a blocking method call at the moment of interruption.

    In all other situations, a thread must check its own interrupted status. If you want to test the class you've written, call a blocking method in your while loop.

    I learnt Java back in university. It's been 4 years since I last coded Java. I develop PHP applications mainly. This time I need a language with more powerful concurrency support. I thought to myself, I'll just revise my Java in an hour and I'm ready to go.

    As it turned out, there is no human friendly tutorials (!!) that can be easily found. I searched "java tutorial" and the first results are either impossibly abstract with no useful code examples or ad-filled spit outs of the Web 1.0 era! More complex searches just led me to more confusing/outdated posts. I just love PHP for the numerous friendly tutorials out there.

    Anyway, to avoid making this a pointless post, can anyone direct me to a readable tutorial to how I can use the thread ExecutorService to 1) queue a few thousand Runnables, 2) have a maximum of 15 threads executing at a time, and 3) if a thread fails, re-queue it or just don't remove it from the Executor's pool.

    Thank you in advance!

    If you dislike Times New Roman, just change the browser default font to Tahoma or something like.

    alt text

    Then start here and click your way through Next link. Then there are the API docs, each with examples in the introductory text. E.g. ExecutorService. Then there are books, like Concurrency in Practice.

    I'm developing a JavaFX application for read data from a serial device and show a notification when a new device is connected to the computer.

    I have a task DeviceDetectorTask which scans all the ports and creates an event when a new device is connected. This task must be submited every 3 seconds.

    When a device is detected the user can press a button to read all the data contained in it. This is performed by another task ReadDeviceTask. At this point and while the ReadDeviceTask is running scan operations should not be performed (I cannot read and scan one port at the same time). So only one of the two task can be running at a time.

    My actual solution is:

    public class DeviceTaskQueue {
        private ExecutorService executorService = Executors.newSingleThreadExecutor();
    
        public void submit(Runnable task) {
            executorService.submit(task);
        }
    }
    
    
    public class ScanScheduler {
        private ScheduledExecutorService executor = Executors.newSingleThreadScheduledExecutor();
    
        public void start() {
            AddScanTask task = new AddScanTask();
            executor.scheduleAtFixedRate(task, 0, 3, TimeUnit.SECONDS);
        }
    }
    
    
    public class AddScanTask implements Runnable {
        @Autowired
        DeviceTaskQueue deviceTaskQueue;
    
        @Override
        public void run() {
            deviceTaskQueue.submit(new DeviceDetectorTask());
        }
    }
    
    public class ViewController {
        @Autowired
        DeviceTaskQueue deviceTaskQueue;
    
        @FXML
        private readDataFromDevice() {
            deviceTaskQueue.submit(new ReadDeviceTask());
        }
    }
    

    My question is: is it ok to add a task to the ExecutorService from the task AddScanTask which has been scheduled by the ScheduledExecutorService?

    Yes, An Executor May Post Task To Another Executor

    To answer your simple question in last line:

    is it ok to add a task to the ExecutorService from the task AddScanTask which has been scheduled by the ScheduledExecutorService?

    Yes. Certainly you can submit a Callable/Runnable from any other code. That the submitting code happens to be running from another executor is irrelevant, as code run from an executor is still “normal” Java code, just running on a different thread.

    That is the whole point of the executor, to handle the juggling of threads in a manner convenient to you the programmer. Making multi-threaded coding easier and less error-prone is why these classes were added to Java. See the extremely helpful book, Java Concurrency in Practice by Brian Goetz et al. And see other writings by Goetz.

    In your case you have two executors each with their own thread, each executing a series of submitted tasks. One has tasks submitted automatically (timed) while the other has tasks submitted manually (arbitrarily). Each executes on their own thread independent of one another. With multiple cores they may execute simultaneously.

    Therein lies the bigger problem: In your scenario you don't want them to be independent. You want the reading tasks to block the scanning tasks.

    Bigger Problem

    The problem you present is that a regularly occurring activity (scanning) must halt when an arbitrary event (reading) happens. That means the two activities must coordinate with one another. The question is how to coordinate.

    Semaphores

    When the arbitrary event is happening, it should raise a flag. The recurring activity, when it runs, should always check for that flag. If raised, wait until the flag lowers before proceeding with scan. The ScheduledExecutorService is designed for this, tolerating a task that may run for a time longer than the scheduled period. If one execution of the task runs long, the SES does not run again, so it does not pile up a backlog of executions. That is just the behavior you want.

    Vice versa, if the recurring activity is executing, it should raise a flag. The arbitrary event’s first to-do item is to check for that flag. If raised, wait until lowered. Then proceed, first raising its own flag and then proceeding with the task at hand (scanning).

    Perhaps your scenario should be designed with a single flag rather than scanner and reader each having their own. I would have to think about it more and probably know more about your scenario.

    The technical term for such flags is semaphore.

    Unfortunately your comment says you cannot alter the scanner’s source code. So you cannot implement the semaphores and coordinate the activities. So I am stuck, cannot see a solution.

    Hack

    Given your frozen code, one hack solution, which I do not recommend, is that the regularly occurring activity (the scanning) not actually do the work but instead post a scanning task on another thread (another executor). That other executor would also be the same executor used to post the arbitrary activity (the reading). So there is one single queue of to-do items, a mix of scanning and reading jobs, submitted to a single-thread executor. The single-thread means they get done one at a time in sequence of their submission.

    I do not like this hack because if any of the to-do items takes a long while you will begin to accumulate a backlog. That could be a mess.


    By the way, no need for the DeviceTaskQueue in your example code. Just call the instance of the ExecutorService directly to submit a task. That is the job of an ExecutorService, and wrapping it adds no value that I can see.

    I mean, why do defacto immutable objects exists? Why do we not just use the final static modifiers? What is so important about String that Java makes it immutable?

    Making a variable final makes that reference unchangeable. But the object that the reference points to can still change, so if I define:

    final List<String> list = new ArrayList<String>();
    

    I can't swap the list out for another list, but I can still modify the contents of the list:

    list.add("asdf");
    

    But an immutable object cannot be changed once it is constructed.

    (Using static only means the field is defined on the class, not on the instance. It's used for defining constant values (moreso before enums were added) but only because only one value is needed for the class. The static keyword's not directly relevant for immutability.)

    Immutable objects are threadsafe and concerns about memory visibility, lost updates, etc. are not applicable, because the object's state is safely published upon construction.

    They are easy to reason about because there are no state changes. For things with value-based equality, immutability is a better match for the concept being described. For Strings and numbers, that are unchanging abstractions, immutability is especially appropriate.

    If you have a mutable object where a mutable field participates in its equals and hashCode implementation, then you can have a situation where you put it in a collection, then mutate the field, breaking how the collection works. It's better to avoid that kind of thing up front.

    Also immutable objects are safer to share, see Java Concurrency in Practice, 3.4:

    Immutable objects are also safer. Passing a mutable object to untrusted code, or otherwise publishing it where untrusted code could find it, is dangerous -- the untrusted code might modify its state, or worse, retain a reference to it and modify its state later from another thread. On the other hand, immutable objects cannot be subverted in this manner by malicious or buggy code, so they are safe to share and publish freely without the need to make defensive copies.

    I'm writing a game engine which performs alhpa-beta search on at a game state, and I'm trying to parallelize it. What I have so far is working at first, and then it seems to slow to a halt. I suspect that this is because I'm not correctly disposing of my threads.

    When playing against the computer, the game calls on the getMove() function of a MultiThreadedComputerPlayer object. Here is the code for that method:

    public void getMove(){
        int n = board.legalMoves.size();
        threadList = new ArrayList<WeightedMultiThread>();
        moveEvals = new HashMap<Tuple, Integer>();
    
        // Whenever a thread finishes its work at a given depth, it awaits() the other threads
        // When all threads are finished, the move evaluations are updated and the threads continue their work.
        CyclicBarrier barrier = new CyclicBarrier(n, new Runnable(){
            public void run() {
                for(WeightedMultiThread t : threadList){
                    moveEvals.put(t.move, t.eval);
                }
            }
        });
    
        // Prepare and start the threads
        for (Tuple move : board.legalMoves) {
            MCBoard nextBoard = board.clone();
            nextBoard.move(move);
            threadList.add(new WeightedMultiThread(nextBoard, weights, barrier));
            moveEvals.put(move, 0);
        }
        for (WeightedMultiThread t : threadList) {t.start();}
    
        // Let the threads run for the maximum amount of time per move
        try {
            Thread.sleep(timePerMove);
        } catch (InterruptedException e) {System.out.println(e);}
        for (WeightedMultiThread t : threadList) {
            t.stop();
        }
    
        // Play the best move
        Integer best = infHolder.MIN;
        Tuple nextMove = board.legalMoves.get(0);
        for (Tuple m : board.legalMoves) {
            if (moveEvals.get(m) > best) {
                best = moveEvals.get(m);
                nextMove = m;
            }
        }
        System.out.println(nextMove + " is the choice of " + name + " given evals:");
        for (WeightedMultiThread t : threadList) {
            System.out.println(t);
        }
        board.move(nextMove);
    }
    

    And here run() method of the threads in question:

    public void run() {
        startTime = System.currentTimeMillis();
        while(true) {
            int nextEval = alphabeta(0, infHolder.MIN, infHolder.MAX);
            try{barrier.await();} catch (Exception e) {}
            eval = nextEval;
            depth += 1;
        }
    }
    

    I need to be able to interrupt all the threads when time is up-- how am I supposed to implement this? As of now I'm constantly catching (and ignoring) InterruptedExceptions.

    The most sensitive way is to use interruption mechanism. Thread.interrupt() and Thread.isInterrupted() methods. This ensures your message will be delivered to a thread even if it sits inside a blocking call (remember some methods declare throwing InterruptedException?)

    P.S. It would be useful to read Brian Goetz's "Java Concurrency in Practice" Chapter 7: Cancellation and Shutdown.

    In my application I have the MainThread and I have a SeperateThread

    I have the threads working almost to perfection. The only problem is I can't shut the SeperateThread down.

    public void run()
    {
        isRunning = true;
        while(isRunning)
        {
            Log.d(TAG, "Running...");
            long currentTime = SystemClock.uptimeMillis();
        }
    }
    
    public void StopThread()
    {
        isRunning = false;
    }
    
    seperateThread.StopThread();
    

    Then in the Thread I have a method that just turns the volatile boolean isRunning off. Even though I step through in the debugger noting that the thread switches the boolean to off.

    • What would cause this type of problem?
    • Is this the cleanest way to shut a thread down?
    • Any other steps in shutting down a thread?
    • Are their any setbacks in Androids multi-threading?

    You definitely want to be using the new concurrency package stuff for this, and grab a copy of Java Concurrency in Practice, and learn more about this. Threads are deceptively simple.

    Why your code isn't working probably has to do with you not setting isRunning to false the way you expect. However, the java.util.concurrency package does this for you anyway.

    In your case you should look at the Executor framework. So your code could look something like this:

        ExecutorService exec = Executors.newFixedThreadPool(1);//A field somewhere
        //Start your thread
        exec.submit(new Runnable(){
            @Override
            public void run() {
                while (!exec.isShutdown()) {
                    Log.d(TAG, "Running...");
                    //Do stuff
                }
            }
        });
        //when done
        exec.shutdown();
    

    Thinking about this overnight, this might be a better way:

        ScheduledExecutorService exec = Executors.newScheduledThreadPool(1);
        exec.scheduleWithFixedDelay(new Runnable() {
            @Override
            public void run() {
               //Do stuff
            }
        }, 0, 1, TimeUnit.MILLISECONDS);
        //when done
        exec.shutdown();
    

    Is there any way to return value (or just return;) for the outer function from the inner function?

    My question is similar to this question: Breaking out of nested loops in Java, but the difference is that in this question the asker asked about breaking the outer loop in nested loops, and I ask about returning for the outer function in nested functions.

    public void outerFunction ()
    {
        runOnUiThread (new Runnable()
        {
            @Override
            public void run ()
            {
                // Here i want to return;, so the function will not continue after runOnUiThread
            }
        });
    
        // Code here should not run.
    
    }
    

    I'm not sure I understand the question. But I assume you are not very familiar with multi-threading.

    The code within Runnable and the code after the call to runOnUiThread actually run at the same time, but on different threads. So it is light-years away from nested loops, or from single-threaded nested methods calls.

    You can actually make a "blocking" call to another thread to wait for a value, but I don't think it's appropriate to write all of this out in a stackoverflow answer. You should read up on multi-threading and I strongly recommend Java Concurrency in Practice. But you should be warned that it is not a trivial topic that you can pick up in a few days. You can also look at this tutorial; the interface Future implements the "blocking" call I was referring to.

    EDIT
    I wrote the above thinking in Java. Things are more complicated with Android since in order to use a Future, you would need to get an ExecutorService for the UI thread, and I'm not sure that is possible.

    There are many Android specific multi-threading constructs (see for example this tutorial, or the official doc). It is certainly possible to solve your problem, but we don't have enough details. Also, you should probably not try to find a quick fix for your problem, but rethink your whole design so that fits naturally within the Android multi-threading paradigm.

    I would like to create a service which will manage a collection through REST-style controller. I was thinking about what is required to make this Service safe from multiple people hitting it at the same time.

    So basically something like this...

    @Transactional
    class NoteService {
        private static users = [:]
        //This won't be so simple it the future
        private static key = 0;
        def get(id) {
            log.debug("We are inside the get")
            return users[id]
        }
        def create(obj){
            log.debug("We are inside the create")
            update(key++, obj)
        }
        def update(id, obj){
            log.debug("We are inside the update")
            users.put(id,obj)
        }
        def delete(id){
            log.debug("We are inside the remove")
            user.remove(id)
        }
    }
    

    Will this work if I have multiple controller requests hitting it at the same time? My concerns are that there could be problems if two clients are trying to hit it at the same time. Also would there be a better strategy maybe using promises? I am using 2.3+

    No, this is broken and not thread-safe.

    If you have no mutable state, you are always thread-safe. Of course if you have no state variables at all then it's even better, but it's fine to have state variables for things like dependency-injected Spring beans, or a logger, etc. As long as you don't change those values, then they're effectively immutable (they get set during startup and aren't changed afterwards), and two concurrent callers won't interfere with each other.

    But you have exactly the thing that is most problematic for concurrent access - a state variable (in this case it doesn't help or hurt that it's static because by default Grails services are singleton Spring beans, so that map could be a non-static instance variable and have the same problems) that you change in multiple methods.

    The easiest thing to do would be to synchronize on the map. You can't just synchronize the methods - that would only work if one method that accessed the map. Using synchronized would serialize the calls and guarantee no concurrent access. But you read and write from multiple methods, so serializing calls to each of those doesn't help the interactions between concurrent calls of different methods. Even if you synchronize every method you are still likely to have occasional instances where two methods get called at the same time; being synchronized doesn't help.

    So you need a mechanism to synchronize across methods, and you're somewhat lucky here since you only have the one mutable field, so you can synchronize on that (but of course you could always create a dummy 'lock' object and synchronize on that if you had multiple fields being changed). Then all access to all methods (whether they're synchronized or not, and you can now un-synchronize them because that's only slowing things down) is guarded by serializing the calls "through" the map.

    This is the easiest, but isn't very performant. If the time spent holding each synchronization lock is short, you probably won't notice much of an issue. Try to make the synchronized blocks as short as possible:

    def update(id, obj) {
       log.debug("We are inside the update")
    
       synchronized(users) {
          users.put(id,obj)
       }
    }
    

    A much better solution would be to use the java.util.concurrent.* locking and concurrency classes that were added in Java 5. This will be very performant if implemented correctly, but getting to the point where you understand how to use these APIs will take a while. The best resource is Java Concurrency in Practice. It was written in 2006 but is still very applicable (it obviously doesn't include updates in newer JDKs, but the APIs available in 1.5 and described in that book are sufficient for many use cases). The book is ~400 pages but the material is difficult (but very well explained), so plan on a multi-month time frame :)

    Venkat Subramaniam's Programming Concurrency on the JVM is another great resource. It's newer (2011) and less in-depth than JCIP, so it covers less but is more approachable. And it covers multiple JVM languages including Groovy. Still a multi-month timeframe, but fewer months.

    i wrote tthe below method to insert records using threads, but at run time i receive "[SQLITE_BUSY] The database file is locked (database is locked)" error,and i think could be due to conflict of sqlite statement.

    i just want to know i am wusing the executorservice correctly in the "insertRecord" method? is there any other variables shoule have been synchronizedß

    code:

    public void insertRecord(String nodeID, String lat, String lng, String xmlpath) throws SQLException, ClassNotFoundException {
    
        if (this.isTableExists(this.TABLE_NAME)) {
    
            InsertRun insRun = new InsertRun(this.psInsert, nodeID, lat, lng, xmlpath);
            this.executor.execute(insRun);
    
        } else {
            Log.e(TAG, "insertRecord", "table: ["+this.TABLE_NAME+"] does not exist");
        }
    }
    
    public void flush() throws SQLException {
        this.psInsert.executeBatch();
    
        this.psInsert.close();
        this.connInsert.close();
    
        Log.d(TAG, "insertRecord", "the rest of the records flushed into data base table.");
    }
    
    private class InsertRun implements Runnable {
    
        private PreparedStatement psInsert = null;
        private String nodeID;
        private String lat;
        private String lng;
        private String xmlPath;
    
        public InsertRun(PreparedStatement psInsert, String nodeID, String lat, String lng, String xmlpath) {
            // TODO Auto-generated constructor stub
            this.psInsert = psInsert;
            this.nodeID = nodeID;
            this.lat = lat;
            this.lng = lng;
            this.xmlPath = xmlpath;
        }
    
        @Override
        public void run() {
            // TODO Auto-generated method stub
            try {
                this.psInsert.setString(1, this.nodeID);
            } catch (SQLException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
            try {
                this.psInsert.setString(2, this.lat);
            } catch (SQLException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
            try {
                this.psInsert.setString(3, this.lng);
            } catch (SQLException e1) {
                // TODO Auto-generated catch block
                e1.printStackTrace();
            }
            try {
                this.psInsert.setString(4, this.xmlPath);
            } catch (SQLException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
    
            try {
                this.psInsert.addBatch();
            } catch (SQLException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
    
            synchronized(this) {
                if (++batchCnt == SysConsts.BATCH_SIZE) {
                    try {
                        this.psInsert.executeBatch();
                    } catch (SQLException e) {
                        // TODO Auto-generated catch block
                        e.printStackTrace();
                    }
    
                    batchCnt = 0;
    
                    Log.d(TAG, "InsertRun", SysConsts.BATCH_SIZE+" records inserted.");
                }
            }
    
        }
    
    }
    

    Additionally, good concurrency design considerations can be difficult to offer without know alot more about the program. Suggest perusing through Java Concurrency in Practice if you plan on writing more multi-threaded applications.

    Let's consider this situation:

    public class A {
        private Vector<B> v  = new Vector<B>();
    }
    
    public class B {
        private HashSet<C> hs = new HashSet<C>();
    }
    
    public class C {
        private String sameString;
    
        public void setSameString(String s){
              this.sameString = s;
        }
    }
    

    My questions are:

    1) Vector is thread-safe so when a thread calls over it, for instance, the get(int index)method Is this thread the only owner ofHashSeths?

    2) If a thread call get(int index) over v and it obtains one B object. Then this thread obtains a C object and invoke setSameString(String s) method, is this write thread-safe? Or mechanism such as Lock are needed?

    Thank you very much for the explanation.

    First of all, take a look at this SO on reasons not to use Vector. That being said:

    1) Vector locks on every operation. That means it only allows one thread at a time to call any of its operations (get,set,add,etc.). There is nothing preventing multiple threads from modifying Bs or their members because they can obtain a reference to them at different times. The only guarantee with Vector (or classes that have similar synchronization policies) is that no two threads can concurrently modify the vector and thus get into a race condition (which could throw ConcurrentModificationException and/or lead to undefined behavior);

    2) As above, there is nothing preventing multiple threads to access Cs at the same time because they can obtain a reference to them at different times.

    If you need to protect the state of an object, you need to do it as close to the state as possible. Java has no concept of a thread owning an object. So in your case, if you want to prevent many threads from calling setSameString concurrently, you need to declare the method synchronized.

    I recommend the excellent book by Brian Goetz on concurrency for more on the topic.

    ok. I need to make three threads: one to get odd numbers, one to get evens, and one to add the odd and evens together. The output would be something like this (1,2,3,3,4,7...). I'm new to threads and still shaky on how they work but this is what I have so far:

    class even extends Thread 
    {
        public void even()
        {
            Thread ThreadEven = new Thread(this); 
            start(); 
        } 
        public void run() 
        {
            try
            {
                for(int i = 0; i < 10; i += 2) 
                {
                    System.out.println(i);
                }
                Thread.sleep(1000);
            }
            catch(Exception e) 
            {
                System.out.println("Error: Thread Interrupted");
            } 
        } 
    }
    
    class odd extends Thread 
    { 
        public void odd() 
        {
            Thread ThreadOdd = new Thread(this); 
            start(); 
        } 
        public void run() 
        {
            try
            {
                for(int i = 1;i < 10; i += 2) 
                System.out.println(i);
                Thread.sleep(1000);
            }
            catch(Exception e) 
            {
                System.out.println("Error: Thread Interrupted");
            } 
        } 
    }
    class ThreadEvenOdd
    {
        public static void main(String args []) 
        {
            even e = new even();
            odd o = new odd();
    
        } 
    } 
    

    This prints out 0,2,4...and then 1,3,5. How to interleave? And is interleaving what I want and should I synchronize the threads as well? What I don't understand is how to get the values of the odd and even thread into a third to add the sum. Apologies beforehand if I didn't get the formatting correct for the code.

    As noted, this is kind of an advanced problem and yes you should be reading lots of tutorials before attempting this. Even for this short program I could never have written it if I had not spent quite a bit of time poring over Java Concurrency in Practice. (Hint - buy the book. It's all in there.)

    The class even and odd are producers. The class sum is a consumer. The producers and consumers share a blocking queue to pass data. The producers use a negative number as a poison pill to indicate that they are finished and no more data will be forthcoming. When the consumer detects the poison pill it decrements the countDown latch. The main thread uses this as a signal that the work is complete.

    import java.util.concurrent.ArrayBlockingQueue;
    import java.util.concurrent.BlockingQueue;
    import java.util.concurrent.CountDownLatch;
    
    
    public class OddEven
    {
       public static void main(String [] args) throws InterruptedException
       {
          BlockingQueue<Integer> evens = new ArrayBlockingQueue<Integer>(1);
          BlockingQueue<Integer> odds = new ArrayBlockingQueue<Integer>(1);
          even e = new even(evens);
          odd o = new odd(odds);
          sum s = new sum(evens, odds);
    
          e.start();
          o.start();
          s.start();
          s.waitUntilDone();
       }
    }
    
    class sum extends Thread
    {
        private final BlockingQueue<Integer> in1;
        private final BlockingQueue<Integer> in2;
    
        private final CountDownLatch done = new CountDownLatch(1);
        public sum(BlockingQueue<Integer> in1, BlockingQueue<Integer> in2)
        {
            this.in1 = in1;
            this.in2 = in2;
        }
    
        public void waitUntilDone() throws InterruptedException
        {
           done.await();
        }
        public void run()
        {
            try
            {
               while (true)
               {
                  int a = in1.take();
                  int b = in2.take();
                  if (a == -1 && b == -1)
                     break;
    
                  int c = a + b;
                  System.out.println(a);
                  System.out.println(b);
                  System.out.println(c);
               }
               done.countDown();
            }
            catch(Exception e)
            {
                System.out.println("Error: Thread Interrupted");
            }
        }
    }
    
    class even extends Thread
    {
        private final BlockingQueue<Integer> out;
    
        public even(BlockingQueue<Integer> out)
        {
           this.out = out;
        }
        public void run()
        {
            try
            {
                for(int i = 0; i < 10; i += 2)
                   out.put(i);
    
                out.put(-1);
            }
            catch(Exception e)
            {
                System.out.println("Error: Thread Interrupted");
            }
        }
    }
    
    class odd extends Thread
    {
       private final BlockingQueue<Integer> out;
    
       public odd(BlockingQueue<Integer> out)
       {
          this.out = out;
       }
        public void run()
        {
            try
            {
                for(int i = 1;i < 10; i += 2)
                   out.put(i);
    
               out.put(-1);
            }
            catch(Exception e)
            {
                System.out.println("Error: Thread Interrupted");
            }
        }
    }
    

    Typical output is:

    0
    1
    1
    2
    3
    5
    4
    5
    9
    6
    7
    13
    8
    9
    17
    Sums are complete
    

    See if you guys could solve this. It is driving me insane.

    I have 2 instances of a Class which has private instance File variables (NOT static, NOT volatile)

    private File tmpF;
    

    each instances were then executed in different threads in the same pool.

    instance 1 and 2 both create a temp file and assigned it to its File variable (NOT static). I called

    tmpF = File.createTempFile("myTempFile" + unique_Id)
    

    right before temp file creation, I debugged using IntelliJ IDEA and verified that each thread has different unique_Id.

    Here is what is driving me insane. When the latter threads created a temp file and assigned it to its own tmpF variable, the earlier thread tmpF variable's value changed to the latter thread's tmpF value. How is this possible when tmpF is NOT static ???

    When I tried changing the variable into a local method variable. The problem disappears... so it is definitely something to do with the fact that is a class field. Adding synchronized doesn't work either interestingly.

    The problem sounds like you are sharing mutable data between threads, which ought to be avoided in concurrent environments, as per Brian Goetz's book, Java Concurrency in Practice. You have a few different options, depending on your restrictions.

    1. If your class instances are really meant to be local to a single thread, try refactor your field so that it is final (i.e. private final File tmpF;), ensuring that it is instantiated exactly once. The file could be injected from a factory class.
    2. If your class has a single instance and is shared between threads and you really need to have each thread use it's own file, try using Java's ThreadLocal class.

    Hope that helps.

    Should FIFO queue be synchronized if there is only one reader and one writer?

    What do you mean by "synchronized"? If your reader & writer are in separate threads, you want the FIFO to handle the concurrency "correctly", including such details as:

    • proper use of FIFO API should never cause data structures to be corrupted
    • proper use of FIFO API should not cause deadlock (although there should be a mechanism for a reader to wait until there is something to read)
    • the objects read from the FIFO should be the same objects, in the same order, written to the FIFO (there shouldn't be missing objects or rearranged order)
    • there should be a bounded time (one would hope!) between when the writer puts something into the FIFO, and when it is available to the reader.

    In the Java world there's a good book on this, Java Concurrency In Practice. There are multiple ways to implement a FIFO that handles concurrency correctly. The simplest implementations are blocking, more complex ones use non-blocking algorithms based on compare-and-swap instructions found on most processors these days.

    Suppose I have one ClassA whose responsibility is to provide thread-safe API for external usage. and some ClassA API has to invoke some method from another ClassB to fulfill some logic (suppose the ClassB's method is stateless and thread-safe). However, ClassB and ClassA can not be merged as a single class due business logic. For example as following code snippet. Is there better way to accomplish this? of course, I could use finer-granularity concurrency control for ClassA such as synchronized block, concurrent lock-free data structures.

    Thanks!

    public class ClassA{
       public synchronized void method1(ClassB cb){
         //do internal stuff1
         cb.printAlog();
         //do internal stuff2
       }
       public synchronized void method2(){
         //do internal stuff3
       }
       ......
    }
    
    public class ClassB{
       public void printALog(){
         //....
       }
       ......
    }
    

    As far as I understood the question, you are wandering about guarding the non-threadsafe code with thread-safe class. At this point of view the code you provided is completely legal, as soon as you don't expose classB in some way, which makes it possible to break the contract of classA.

    This design is also described in Java concurrency in practice very well.

    Suppose you have a work queue and there can be thousands of work items. And assume updates for different work items keep coming into the system. Now obviously if we get multiple updates for the same work item, that needs to be locked.

    In this situation we can easily run into a situation, where the system could have received 2000 (or some high number) updates at once and hence JVM needs to hold 2000 locks on different objects.

    Will it degrade JVM performance alot? Is there any maximum number of locks that JVM can hold at once to not let performance degrade.

    I understand you can use hashing technique to stop the number of locks from growing.

    Each lock merely stores the object holding it. The first part of the question--how many locks can the JVM hold--is like asking how many 12s it can store. The amount is bounded by memory. As others have noted, performance is impacted most by lock contention.

    Use the classes from java.util.concurrent to build and store your locks and work queue as they were written for safety and performance. I highly recommend the book Java Concurrency in Practice.

    we have been trying to benchmark our application performance in multiple way for sometime now. I always believed that object creation in java using Class.newInstance() was not slow (at least after 1.4 version of java). But we anyways did a test to use newInstance method vs mainitain an object pool of 1000 objects. We did about 200K iterations of loading data from DB using JDBC and populating these objects. I was amazed (even shocked) to see that newInstance code compared to object pool code was almost 10 times slower.

    These objects represent tables with about 50 fields and all string type.

    Can someone share there thoughts on this issue as now I am more confused if object pooling of atleast some DAO instances is a better option. The pool size as I see right now should be large enough to meet size of average requests. There is a flip side as my memory footprint will go up but I am beginning to wonder if this kind of idea makes sense atleast for some of the DAO entities representing tables of about 50 or more columns

    Please share your ideas and let me know if this has been tried by someone or am I missing some point here

    To quote from Java Concurrency in Practice:

    Just say no to object pools

    There is likely a simpler option to whatever problems you are having. For instance, why are you instantiating so many instances of your DAOs in the first place? Is a new DAO instance being created every time you need to retrieve data from the database?

    Why not just re-use the same instance of the WhateverDao each time you need access to the Whatever data? Just make sure that the DAO is thread-safe.

    When writing a thread safe class, we use synchronized keyword at two places in code,

    1.Method level synchronization

    2.Synchronized blocks

    As far as I can think of, interfaces like Lock (java.util.concurrent.locks.Lock)can be used in place of synchronizedonly at block level but not at method level. or is there a way?

    I don't have any real need of it but just curios since heard discussions that Lockcan be a replacement for synchronized.

    public class SampleClass {
        public synchronized void method(){
          .....
        }
    }
    

    No, there's no way to do this since java.util.concurrent—and therefore Lock or any other implementation as well—is just a library, whereas synchronized is part of the Java Language Specification.

    Regarding "Lock can be a replacement for synchronized", Brian Goetz discusses this in "Java Concurrency in Practice" in chapter 13.4:

    ReentrantLock is an advanced tool for situations where intrinsic locking is not practical. Use it if you need its advanced features: timed, polled, or interruptible lock acquisition, fair queueing, or non-block-structured locking. Otherwise, prefer synchronized.

    While reading java concurrency in practice (btw, an excellent book), I ended up with the following related questions. The first one is about documenting thread safety, the second is about proving that a class that depends on an interface is thread safe.

    Question 1. Does it make sense to use @ThreadSafe on interfaces? Is it a way of communicating that all the implementations must be thread safe? I am still trying to make up mind here, not sure if it is a good practice or not.

    Consider the following example.

    public interface Point {
        int getX();
    }
    
    class ImmutablePoint implements Point {
        private final int x;
    
        public ImmutablePoint(int x) {
            this.x = x;
        }
    
        @Override
        public int getX() {
            return x;
        }
    }
    
    class MutablePoint implements Point {
        public int x;
    
        public MutablePoint(int x) {
            this.x = x;
        }
    
        @Override
        public int getX() {
            return x;
        }
    }
    

    Question 2. Let's assume that you need to decide if the following class is ThreadSafe or not

    // How can someone possibly know if this class is thread safe or not?
    class IsItThreadSafe {
        private final int aRandomField;
        // the custom Point defined before
        private final Point point;
    
        public IsItThreadSafe(int aRandomField, Point point) {
            this.aRandomField = aRandomField;
            this.point = point;
        }
    
        public int add(){
            return aRandomField + point.getX();
        }
    }
    

    Since this class only depends on the interface Point, and we don't know anything about the implementation at this point (haha), how can you know if your class is thread safe or not?

    I can imagine the follow scenario (pseydo code)

    class ConcurrentRunner{
        public void run() {
            MutablePoint mutablePoint = new MutablePoint(42);
            IsItThreadSafe isItThreadSafe = new IsItThreadSafe(13, mutablePoint);
    
            // here pass isItThreadSafe and mutablePoint to multiple threads
            // each thread can modify mutablePoint and then run add()
            // different threads may get different results, the class is not behaving 
            // the same, so it should not be treated as thread safe.
        }
    }
    

    What do you think guys? I am sure that I am missing something fundamental here, but I don't know what!

    I have seen this from a recognised sample book so its hard to question then there is something I dont understand.

    A class called DataflightsService contains a private static variable called FlightFileAccess that appears to be instantiated everytime we create a new object for DataflightsService as FlightFileAccess's initiation its in the constructor

    ie

    public class DataflightsService{
        private static FlightFileAccess fileAccess=null;
    
        public DataflightsService(String path){
             fileAccess=new flightFileAccess(path);
        }
    
        public boolean removeflight(String code){
             //We use this static instance that wraps functionality to remove a flight
             fileAccess.remove(code);
        }
    }
    

    For me that means that every time we create an instance of DataflightsService, in the constructor are using a different object all the time for the static variable FlightFileAccess

    In the original FlightFileAccess Class: we have the remove method that synchronizes a RandomAccessFile

    Class FlightFileAccess{
        private RandomAccessFile database = null;
        private boolean remove(String code){
            // Other code goes here and there
    
            synchronized (database) {
                 //Perform deletion code
            }
        }
    

    So because we are using a different reference of FlightFileAccess we are also using a different reference of RandomAccessFile?

    That means that having FlightFileAccess as static in service does not serve here to synchronize on the RandomAccessFile because it is a new one every time so each DataflightsService instance will do their thing on the random access file ignoring the synchronization. As opposed to instantiating FlightFileAccess in a static initiator. Am I right?

    I would appreciate as many explanations as possible to provide the best way to be able to instantiate DataflightsService as many times as we want (as lets say imagining each client has their own instance of DataflightsService) and after that being able to synchronize on a file for removals for example so that there is no mess of several clients accessing the file. Sorry I need to include a DataflightsService per client bc there are no cookies.

    Your example won't compile because the name of the constructor doesn't match the class. But if you mean to name the constructor public DataflightsService(), then part of the issue is that you are overwriting the static variable each time a new object is created.

    It sounds like you want this static variable to be initialized only once. Normally you would just assign the variable directly with private static final FlightFileAccess fileAccess = new FlightFileAccess(); or if you wanted to add more logic as if you had a constructor, you could use a static initializer block as follows:

    public class Dataflights {
    
        private static final FlightFileAccess fileAccess;
    
        static {
          // Static initializer block gets run once when the class is first referenced.
          // Not usually used unless you want to add more logic besides just initializing variables.
          fileAccess = new FlightFileAccess();
        }
    
        private final String path;
        public final int id;
    
        public Dataflights(String path) {
          this.path = path;
          this.id = fileAccess.generateId();
        }
    
      static class FlightFileAccess {
    
        private volatile int nextId = 0;
        synchronized public int generateId() {
          return nextId++;
        }
      }
    
      public static void main(String[] args) {
        Dataflights d = new Dataflights("my/path");
        System.out.println("Id is: " + d.id);
      }
    }
    

    There are many ways to handle contention. I recommend Java Concurrency in Practice if you aren't familiar with Java concurrency.

    You are on the right track in your FlightFileAccess class. I can't see the details, but you might also want to use the synchronized keyword in the signature of the remove() method to protect the entire function first. Then, once you have things working, use more tightly targeted synchronize {...} blocks to reduce the amount of code that has to be singly threaded.

    In one thread I have

    write a = 0
    write a = 1
    write volatile flag = 1
    

    In 2nd thread I have

    read volatile flag // This always happens after I write volatile flag in thread 1
    read a
    

    Can a reordering happen so I see read a returning 0 in the 2nd thread?

    If not, could someone, please, explain in detail why?

    I'm asking becuase I'm puzzled by this definition from the JLS:

    Among all the inter-thread actions performed by each thread t, the program order of t is a total order that reflects the order in which these actions would be performed according to the intra-thread semantics of t.

    It looks as if allows for reordering in this situation?

    Can a reordering happen so I see read a returning 0 in the 2nd thread?

    No, not if your assertion is correct, "This always happens after I write volatile flag in thread 1"

    The last update that thread 1 made to the variable a before it updated the volatile flag will be visible to thread 2 after thread 2 has read the volatile flag.

    See section 3.1.4 of Java Concurrency in Practice by Brian Goetz for a more detailed explanation: http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/dp/0321349601


    But note! It can be considered to be bad practice to depend on reads and writes of a volatile variable to synchronize other variables. The problem is, the relationship between the volatile variable and the other variables may not be obvious to other programmers who work on the same code.

    I've been watching a lot of videos on data structures, and these terms are always being mentioned: synchronized/not synchronized and thread-safe/not thread-safe.

    Can someone explain to me in simple words what synchronized and thread-safe mean in Java? What is sync and what is thread?

    As per CIP:

    A class is thread-safe if it behaves correctly when accessed from multiple threads, regardless of the scheduling or interleaving of the execution of those threads by the runtime environment, and with no additional synchronization or other coordination on the part of the calling code.

    So thread safety is a desired behavior of the program in case it is accessed by multiple threads. Using the synchronized block is one way of achieving that behavior. You can also check the following:

    What does 'synchronized' mean?

    What does threadsafe mean?

    An attempt to signal between 2 threads with minimum wasted signals. Since it has been some time I have attempted this - please suggests errors/improvements if any. The intention is : 1.no deadlock 2.no updates being missed from being read 3.not raising missed signals as far as possible.

    import java.util.Random;
    class shareful{
    
        class share{
            int sharedata;
            volatile boolean  isbitset=false;
            public int getstats(){
                return sharedata;
            }
            public void setstats(int data){
                sharedata=data;
            }
    
            public boolean getbitset(){ return isbitset;}
            public void setbitset(boolean flag){ isbitset=flag;}
        }
        share so=new share();
        void runStatistics(){
            int check=0;
            Thread t1=new Thread(new Runnable(){
                public void run(){
                    Random r=new Random();
                    boolean isflagged=false;
                    while (true){
                        synchronized(so){
                            try{
                                while(so.getbitset()==true){
                                            so.wait();
                                }
                            }
                            catch(InterruptedException e){}
                            so.setstats(r.nextInt(200));
                            if(so.getbitset()==false) isflagged=true;
                            so.setbitset(true);
                            if(isflagged) so.notify();
    
                        }
                    }
    
    
                }
            });
    
            Thread t2=new Thread(new Runnable(){
                public void run(){
                    boolean isflagged=false;
                    while(true){
                        synchronized(so){
                                try{
                                        while(so.getbitset()==false){
                                        so.wait();
                                    }
                                }
                                catch(InterruptedException e){}
                                int curr=so.getstats();
                                if(so.getbitset()==true) isflagged=true;
                                so.setbitset(false);
                                if(isflagged) so.notify();
                        }
    
                    }
                }
            });
    
            t1.start();
            t2.start(); 
    
    
        }
    
        public static void main(String[] args){
            shareful s=new shareful();
            s.runStatistics();
        }
    
    
    }
    

    Suggestions in order of effectiveness (or by inverse sanity, depending on your perspective):

    1. Stop trying to manage threads manually and instead use a proven paradigm for managing concurrency like actors or software transactional memory depending on what fits your needs.
    2. Don't use mutable state when dealing with concurrency.
    3. If you must use mutable state, at least don't use any shared mutable state.

    Additional suggestion: read Brian Goetz' "Java Concurrency in Practice" to discover that you should never attempt to write code at this level in a typical application.

    Due to many misunderstandings, I've reformulated this question from ground up. The intention of the question is unchanged. Many comments still refer to the old question text.

    The documentation about volatile states that it ensures that other threads see memory updates in a consistent fashion. However, volatile is used rarely.

    As far as I know, the purpose of synchronized blocks is to cause threads not to execute these critical sections simultaneously. Does synchronized also cause consistent memory updates to other threads, like volatile does?

    Java doesn't really have a concept of "volatile memory". Instead, the volatile keyword changes the guarantees the JVM makes about when and how a field will be written and read. Wikipedia has a decent breakdown of what Java (and other languages) mean by volatile.

    Very roughly speaking, a volatile field is equivalent to a field that is always read-from and written-to like so:

    // read
    T local;
    synchronized {
      local = field;
    }
    
    // ... do something with local
    
    // write
    synchronized {
      field = local;
    }
    

    In other words, reads and writes of volatile fields are atomic, and always visible to other threads. For simple concurrency operations this is sufficient, but you may well still need explicit synchronization to ensure compound operations are handled correctly. The advantage of volatile is that it's smaller (affecting exactly one field) and so can be handled more efficiently than a synchronized code block.

    You'll notice from my psuedo-translation that any modifications or mutations to the field are not synchronized, meaning there is no memory barrier or happens-before relationship being imposed on anything you might do with the retrieved object. The only thing volatile provides is thread-safe field reads and writes. This is a feature because it's much more efficient than a synchronized block when all you need is to update a field.

    I would strongly encourage you to read Java Concurrency in Practice if you haven't before; it provides an excellent overview of everything you need to know about concurrency in Java, including the difference between volatile and synchronized.


    Obviously, this doesn't happen, or else I would have encountered such a problem during my career. I never did.

    Note that this is a fallacious line of reasoning. It is perfectly possible for you to do something wrong yet never be affected by it or simply not notice its effects. For instance over-synchronized code (like Vector) will work correctly but run much slower than alternative solutions.

    when I'm trying to execute the following multhiThreading code multiple times ,the output is not same as previous one . Is that because of JVM behaviour or may be some other reason . please help me some one.

    program:
    
    
    package example.thread.com;
    
    class MyThread1 implements Runnable {
        Thread t;
    
        MyThread1(String s) {
            t = new Thread(this, s);
            t.start();
        }
    
        public void run() {
            for (int i = 0; i < 5; i++) {
                System.out.println("Thread Name  :"
                        + Thread.currentThread().getName());
                try {
                    Thread.sleep(2000);
                } catch (Exception e) {
                }
            }
        }
    }
    
    
    public class RunnableThread1 {
        public static void main(String args[]) {
            System.out.println("Thread Name :" + Thread.currentThread().getName());
            MyThread1 m1 = new MyThread1("My Thread 1");
            MyThread1 m2 = new MyThread1("My Thread 2");
        }
    }
    

    output: if i run 1st time

    Thread Name :main
    Thread Name  :My Thread 1
    Thread Name  :My Thread 2
    Thread Name  :My Thread 1
    Thread Name  :My Thread 2
    Thread Name  :My Thread 2
    Thread Name  :My Thread 1
    Thread Name  :My Thread 1
    Thread Name  :My Thread 2
    Thread Name  :My Thread 1
    Thread Name  :My Thread 2
    

    output: if i run 2nd time

    Thread Name :main
    Thread Name  :My Thread 2
    Thread Name  :My Thread 1
    Thread Name  :My Thread 2
    Thread Name  :My Thread 1
    Thread Name  :My Thread 2
    Thread Name  :My Thread 1
    Thread Name  :My Thread 1
    Thread Name  :My Thread 2
    Thread Name  :My Thread 1
    Thread Name  :My Thread 2
    

    output: if i run 3rd time

    Thread Name :main
    Thread Name  :My Thread 1
    Thread Name  :My Thread 2
    Thread Name  :My Thread 2
    Thread Name  :My Thread 1
    Thread Name  :My Thread 1
    Thread Name  :My Thread 2
    Thread Name  :My Thread 2
    Thread Name  :My Thread 1
    Thread Name  :My Thread 2
    Thread Name  :My Thread 1
    

    like this please suggest .....

    The effect you see is only partly the result of JVM behavior. The JVM merely creates the threads and starts them. The operating system is responsible for deciding which thread runs on which processor when. Your threads will contend for use of a processor not just with each other, but with all the work your computer is doing.

    When a thread sleeps, it stops being a runnable thread that can use a processor. When it gets to the end of its sleep time it goes back to being runnable, and contending for use of a processor. At some time after that, the operating system will pick it as the thread to run on a processor, and it will go on computing. It keeps the processor until it terminates, sleeps, has to wait for something else, or the operating system decides it is another thread's turn.

    There is no reason to expect the ordering between the two threads to be the same from run to run. Writing multi-threaded programs that give consistent results takes some effort.

    I suggest starting with some basic tutorials on multi-thread programming. When you are ready to learn more deeply about the subject, I recommend Java Concurrency in Practice

    Realated tags

    .netalgorithmandroidandroid-ndkandroid-servicearraylistasynchronousatomicatomicityblackberryblockingblockingqueuecc#c++callbackclient-serverclonecollectionsconcurrencyconcurrent-programmingconcurrenthashmapconditional-statementscpu-usagecsvcyclicbarrierdaemondaodata-structuresdeadlockdelphideprecateddesigndistributeddouble-checked-lockingdynamiceclipseencapsulationevent-dispatch-threadeventsexceptionexecutorexecutorservicefilesystemsfinalfinallyflood-fillfunctionfuturegrailsguavagwtheuristicshibernateimmutabilityinfinite-loopinheritanceinner-classesinstanceinterpreterinterruptinvokelaterjavajava-7java-eejava-mejava.util.concurrentjavafxjdbcjlsjsfjvm-hotspotlanguage-agnosticlistlistenerlocal-variableslockingloggingmemorymemory-barriersmemory-leaksmemory-managementmethodsmidimodelmouseeventmulticoremultithreadingmutexnestednested-classnon-staticnullnullpointerexceptionobserver-patternopenjdkoperating-systemoptimizationoracle11gorderoverloadingparallel-processingperformanceproducer-consumerprogram-flowprogramming-languagesproject-planningpthreadsrace-conditionrandomreal-timereflectionrubyruby-on-railsrunnablescalascala-2.10scheduledexecutorserviceseamserial-portservletsside-effectssingletonsmacksocketsspringspring-batchsqlitestatestaticstringstringbufferstringbuilderswingsynchronizationsynchronizedterminationtestingthread-localthread-prioritythread-safetythreadgroupthreadpooltimeouttimertimertaskunit-testinguser-interfacevariablesvectorverificationvisualizationvolatilewaitwhile-loopwindowsxmpp