1

I have a class with a global variable, Integer clock, initialized to 0. It passes 'clock' to a few thread constructors, starting the threads also. It seems increments to 'clock' can be seen within the thread, but in their calling process, 'clock' is always 0. Because Integer is an object and objects are passed by reference, I would expect changes to 'clock' to be seen everywhere. Is this not the case?

Rooster
  • 1,267
  • 3
  • 15
  • 23
  • 1
    Java is *pass by value* - specifically the *reference value*. Aside from that though, `Integer` (actually, all the autobox classes) is immutable; you can't alter it. – Brian Roach Nov 15 '11 at 01:37

2 Answers2

5

Use an AtomicInteger instead of an Integer.

An int value that may be updated atomically. See the java.util.concurrent.atomic package specification for description of the properties of atomic variables. An AtomicInteger is used in applications such as atomically incremented counters, and cannot be used as a replacement for an Integer. However, this class does extend Number to allow uniform access by tools and utilities that deal with numerically-based classes.

Matt Ball
  • 354,903
  • 100
  • 647
  • 710
0

Integer is an immutable object so you cannot change its value from another thread. And since it must be declared final when you use it in the thread you cannot reassign the variable.

A way around this is to create a wrapper for Integer that is mutable

class MutableInteger {
   private int integer;

   synchronized void setInteger(int integer) { ... }
   synchronized int getInteger() { ... }
}
Garrett Hall
  • 29,524
  • 10
  • 61
  • 76
  • Duh, forgot about that. But creating a Clock object with an int field and calling increment() would work right? – Rooster Nov 15 '11 at 01:37
  • Yes, and if you are writing/reading from multiple threads you should probably use the `synchronized` modifier to keep it thread-safe. – Garrett Hall Nov 15 '11 at 01:38
  • Ah ok, that's analogous to my Clock object. Thanks! – Rooster Nov 15 '11 at 01:39
  • Okay, so I have to downvote this answer. It's not wrong, _per se_, but there are some serious flaws that need to be addressed. You're absolutely right about `Integer` being immutable, and that's a great start! But then you recommend a custom class which, aside from being [completely unnecessary](http://stackoverflow.com/questions/8130448/passing-integer-by-reference-with-threads/8130510#8130510), is not remotely threadsafe. And, at that rate, why would you wrap an `Integer` instead of an `int`? – Matt Ball Nov 15 '11 at 01:46
  • Funny, I upvoted you. Anyway, all valid points, I wrote it quickly as an example, but he is using a `Clock` class anyway so he doesn't really need an Integer wrapper. – Garrett Hall Nov 15 '11 at 01:54
  • @EJP http://stackoverflow.com/questions/4785073/why-should-my-local-variables-be-final-to-be-accessible-from-anonymous-class – Garrett Hall Nov 15 '11 at 02:10
  • The `final` bit is only _strictly_ necessary if the OP is constructing anonymous subclasses of `Thread`, though in general it doesn't hurt. Where do you see anything about a `Clock` class? – Matt Ball Nov 15 '11 at 02:15
  • @Garret Hall I'm aware of when things really must be declared final. The words used by the poster remain incorrect. – user207421 Nov 15 '11 at 02:39