Java Keywords (Part XXII): volatile

Java keyword list

abstract continue for new switch
assert default goto* package synchronized
boolean do if private this
break double implements protected throw
byte else import public throws
case enum instanceof return transient
catch extends int short try
char final interface static void
class finally long strictfp volatile
const* float native super while
Keyword marked with an asterisk (*) are keywords that, although valid, are not used by programmers.
In the last article, we learned about the use of synchronized keyword, and we scratched the surface a little bit about concurrency. The keyword volatile is also relevant in concurrency. To learn more about why this keyword is applicable to concurrency, please read about Atomic Access. You could also read the Threads and Locks section of the Java Specification.

As we learned before, the Java programming language allows threads to access shared variables. To ensure that shared variables are consistently and reliably updated, a thread should ensure that it has exclusive use of such variables by obtaining a lock that enforces mutual exclusion for those shared variables. The previous article covered the use of the keyword synchronized for this purpose. You could use synchronized methods or synchronized statements to achieve this. However, Java provides a second mechanism: volatile fields or variables. This is actually more convenient than locking in some cases. As a reminder, this article is only to show how to use the keyword, not why you should use it. To learn the why, please visit the sites I provided. That said, I will point out that a field may be declared volatile, in which case the Java Memory Model ensures that all threads see a consistent value for the variable. Also, it is a compile-time error if a final variable is also declared volatile. In other words, constants need not to be marked as volatile.

The keyword volatile is one type of Java's field modifiers. Throughout this series, you learn about other fields modifiers such as static, and final. Ths article covers volatile, and the next will cover transient. To use volatile, simply add it after a variable's access modifier like this:

BAD USE: 


final volatile int MY_CONSTANT = 3; // THIS IS A COMPILE-TIME ERROR!!
GOOD USE: 

static volatile int myVariable = 3; // THIS IS OK!! 
private volatile SomeClass otherVariable = new SomeClass(); // THIS IS ALSO OK!!
Basically, volatile can be used with primitive or non-primitive fields as field modifier, and combined with other field modifiers, except for final. Next up, Part XXIII: transient

Comments

Post a Comment

Popular posts from this blog

Implementing Interfaces with Java Records

If you have not read my article on Java records and do not know about this topic, please read my blog titled " Customizing Java Records " first and then come back to this one. Now that you know how to customize Java records, implementing an interface using Java records should be very easy to understand. If you don't know about interfaces in Java, you can read more on my article about interfaces. The recipe for implementing an interface is simply an expansion of what you learned in my previous blog on how to customize a Java record. Following our Rectangle example, let's create an interface with the same two methods we used before. public interface Shape { double area(); double perimeter(); } Now, let's further customize the previous example by doing two things: Add implements Shape at the end of the record declaration (after the record constructor), and Add @Override to the existing methods to ensure these methods com...
Read more

Customizing Java Records

If you have not read my article on Java records and do not know about this topic, please read my blog titled " Java Keywords Addendum: The Java Record " first and then come back to this one. What is a customization of a record? A customization of a record is simply the addition of code inside the body of the class. Before proceeding further, let's recap important aspects of a Java Record: Java records are immutable Because of item 1 above, you cannot add new fields unless defined in the record constructor Java records already override: Object#equals(Object) and Object#hashCode() , and then override Object#toString() You could redefine overridden methods as part of your customization if you would like. For example, if you want a fancier implementation of the Object#toString() method, you could do so. Let's look at our first customization example. Using the example from my previous blog, public record Student(...
Read more

Exception Handling: File CRUD Operations Example

Image
Introduction to Exception Handling This is a supplement to my previous blog Creating Custom Exception Classes in Java . I recommend you read that one first and then read this one. Java provides many Exception (and Error) Handling classes. Both of these categories implement the Throwable interface. Although it is not imperative that you develop your own custom exception classes, it is often a good idea to do so; particularly when dealing with large systems. The main reason to create custom exception classes is to quickly identify which custom class is being affected or causing these custom exceptions. For example, referencing a null object and trying to use it will result in a NullPointerException . However, in your code, there could be literally hundreds or even thousands of statements which could result in such exception. Designing your Custom Exception Class Suppose that you are designing a class that will serve as a message receiver. For simplicity, ...
Read more