Java provides several built-in synchronization primitives to manage concurrent access to shared resources, including locks, semaphores, and atomic classes. Atomic classes are a unique type of synchronization primitive that allows for lightweight concurrent access to shared resources without the need for locks or semaphores.

In this article, we will delve into the concept of atomic classes in Java, their
implementations, and best practices for using them effectively.

First thing first : What are Atomic Classes in Java?

  Atomic classes are built-in synchronization primitives in Java that allow multiple threads to access a shared resource concurrently without the need for locks or semaphores. They provide a lightweight and efficient way to manage concurrent access to shared resources, making them ideal for high-contention scenarios. In this article we will not go into the pitfalls of multi-threading while using non-thread-safe variable.

Atomic classes can be used to implement a variety of synchronization primitives,
including

Atomic variables

Atomic variables are simple variables that can be accessed by multiple threads simultaneously without the need for locks or semaphores.
They provide a convenient way to share data between threads without worrying about race conditions. Here is an example of how atomic
variables can be used:

public static class AtomicVariableExample {
            /**
     * Atomic variable to track how many time the operation has been * completed
     */
    private static final AtomicLong completed = new AtomicLong(0);
    private static Long nonThreadSafeVariable = 0L;

    public static void main(String[] args) throws InterruptedException{
        // Using Atomic Variable
        Runnable atomicTask = () -> {
            completed.incrementAndGet();
            System.out.println("Incremented atomic variable " + completed.get());
        };

        // Using synchronized block
        Runnable synchronizedTask = () -> {
            synchronized (AtomicVariableExample.class) {
                nonThreadSafeVariable++;
                System.out.println("Incremented non thread safe variable "+ nonThreadSafeVariable);
            }
        };
        var executor = Executors.newVirtualThreadPerTaskExecutor();
        for (var i = 0; i < 10; i++) {
            executor.submit(atomicTask);
            executor.submit(synchronizedTask);
        }
        executor.awaitTermination(5, TimeUnit.SECONDS);
        
    }
    }

Atomic operations

Atomic operations are methods that perform a single operation on an atomic variable, such as incrementing or decrementing its value. These methods ensure that the operation is executed atomically, meaning that either the entire operation is completed, or it is rolled back and tried again if there is a failure. One might assume that incrementing or decrementing a variable is a single operation therefor there is no need for such complexity. However incrementing a variable myVariable++ is actually two operations first you read the current value, then add one to it, and finally you assign that computed value to the variable myVariable= myVariable + 1.
Now that we got this out the way, here's  an example of how atomic operations can be used:

Compare And Swap

package multithreading;

import java.util.Random;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicInteger;
import java.util.concurrent.atomic.AtomicIntegerArray;

public class CompareAndSwapOperation {
    public static AtomicInteger atomicInteger = new AtomicInteger(0);
   
    public static void main(String[] args) throws InterruptedException {
        final var gen = new Random();
        final var executor = Executors.newVirtualThreadPerTaskExecutor();
        /**
         * CompareAndSwap (method named comparedAndSet)
         * this method compares the current value of the variable 
         * to an expected value, they are the same it set a new value and returns true
         * if the are not the same, it doesn't set the value and returns false
         */
        Runnable task = () -> {
            var guessedValue = gen.nextInt(0, 10);
            var randomNewValue = gen.nextInt(0, 10);
            var correctGuess = atomicInteger.compareAndSet(guessedValue, randomNewValue);
            if (correctGuess) {
                System.out.println("We guess that the value was " + guessedValue + " and that was " + correctGuess
                        + " new value will be " + randomNewValue);
            }
        };
        
        for (var i = 0; i < 1000; i++) {
            executor.submit(task);
        }
        executor.awaitTermination(10, TimeUnit.SECONDS);
    }

}

There are many others atomic operations that we have not covered but I think this ones are the most important and the most used.

Best Practices

1. Use atomic classes sparingly:
   Atomic classes should be used sparingly and only when necessary to avoid unnecessary overhead. They are best suited for situations where
   a lightweight synchronization mechanism is required.
2. Use locks or semaphores in addition to atomic classes:
   In some cases, you may want to use locks or semaphores in conjunction with atomic classes to provide an additional layer of
   synchronization. This can help ensure that your code is both correct and efficient.
3. Test your code extensively:
   Test your code thoroughly to ensure that it behaves correctly under different scenarios, including high-contention situations. This will
   help identify any issues or bugs that may arise due to the use of atomic classes.

Conclusion

In conclusion, atomic classes are a powerful tool in Java for managing concurrent access to shared resources without the need for locks
or semaphores. By understanding their implementations and best practices, developers can create efficient and scalable multi-threaded
applications. Whether you're working on a simple web application or a complex enterprise system, mastering the art of atomic classes can
help you build robust and reliable software.

Multithreading is a fundamental aspect of modern software development, allowing developers to create applications that can handle
multiple tasks simultaneously. However, managing concurrent access to shared resources is crucial to avoid race conditions and other
synchronization issues. In Java, locks provide a simple way to synchronize access to shared resources, ensuring that only one thread can
access the resource at a time. In this article, we will delve into the concept of locks in Java, their implementations, and best
practices for using them effectively.

What are Locks in Java?

A lock is a synchronization primitive that controls access to a shared resource. It ensures that only one thread can access the resource
at a time, preventing race conditions and deadlocks. In Java, locks are implemented using wait-and-signal semantics, where threads wait
for each other to release the lock before acquiring it themselves.

There are three built-in synchronization primitives in Java: ReentrantLock, ReentrantReadWriteLock, and Semaphore. Each of these locks
has its own strengths and weaknesses, which we will explore below:

1. ReentrantLock:
   ReentrantLock is the most commonly used lock implementation in Java. It provides a simple way to synchronize access to shared resources
   by implementing the wait-and-signal semantics. The lock can be acquired and released by any thread, but only one thread can hold the lock
   at a time. ReentrantLock provides two methods for synchronization:

• acquire() : Acquires the lock, allowing the calling thread to access the shared resource.
• release() : Releases the lock, allowing other threads to acquire it.

Example Code:

public class MyThread extends Thread {
    private static ReentrantLock lock = new ReentrantLock();
    
    public void run() {
        System.out.println("Starting thread");
        try {
            lock.acquire(); // Acquires the lock
            // Critical section of code here
            System.out.println("Finished critical section");
            lock.release(); // Releases the lock
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

1. ReentrantReadWriteLock:
   ReentrantReadWriteLock is similar to ReentrantLock but provides read-write locks instead of just read or write locks. Read-write locks
   allow multiple threads to read and write shared resources concurrently, making them useful for synchronizing access to large datasets.
   The lock can be acquired and released by any thread, but only one thread can hold the lock at a time. ReentrantReadWriteLock provides two
   methods for synchronization:

• acquireRead() : Acquires the read lock, allowing the calling thread to read the shared resource.
• acquireWrite() : Acquires the write lock, allowing the calling thread to modify the shared resource.

Example Code:

public class MyThread extends Thread {
    private static ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
    
    public void run() {
        System.out.println("Starting thread");
        try {
            lock.acquireRead(); // Acquires the read lock
            // Reading shared resource here
            System.out.println("Finished reading shared resource");
            lock.releaseRead(); // Releases the read lock
            
            lock.acquireWrite(); // Acquires the write lock
            // Modifying shared resource here
            System.out.println("Finished modifying shared resource");
            lock.releaseWrite(); // Releases the write lock
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

1. Semaphore:
   Semaphore is a synchronization primitive that allows a set number of threads to access a shared resource concurrently. It provides a more
   fine-grained control over concurrent access to shared resources compared to ReentrantLock and ReentrantReadWriteLock. Semaphore can be
   acquired and released by any thread, but only a fixed number of threads can hold the lock at a time.

Example Code:

public class MyThread extends Thread {
    private static Semaphore semaphore = new Semaphore(5); // Maximum 5 threads can access shared resource concurrently
    
    public void run() {
        System.out.println("Starting thread");
        try {
            semaphore.acquire(); // Acquires the lock
            // Accessing shared resource here
            System.out.println("Finished accessing shared resource");
            semaphore.release(); // Releases the lock
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

Best Practices:

1. Avoid busy waiting:
   Busy waiting occurs when a thread waits indefinitely for a lock to become available. Instead, use timeouts or other mechanisms to handle
   cases where a thread is blocked waiting for a lock indefinitely.
2. Use timers for idle periods:
   In situations where a thread is blocked waiting for a lock, it can use a timer to detect when a certain amount of time has passed. This
   can help avoid wasting CPU cycles.
3. Consider using other synchronization primitives:
   Depending on the complexity of your application, you may want to consider using other synchronization primitives such as queues or
   messages, which can provide more fine-grained control over concurrent access to shared resources.
4. Use locks sparingly:
   Locks should be used sparingly and only when necessary to avoid unnecessary delays and CPU usage.
5. Test your code thoroughly:
   Test your code extensively to ensure that it behaves correctly under different scenarios, including high-contention situations.

Conclusion:

In conclusion, locks are a crucial aspect of multithreading in Java. By understanding the different lock implementations available and
following best practices for their use, developers can create efficient and scalable concurrent applications. Whether you're working on a
simple web application or a complex enterprise system, mastering the art of synchronization can help you build robust and reliable
software.

Console.log is probably the most written line of code in the JavaScript language. Developers often use this function as a way to display values, assert value, create false breakpoints and so on. In this post we will explore some other functions that can help you write better code and avoid the "console.log" overdose.

Console.assert
Often what we want to achieve is to evaluate a condition in our code and print something int he console in case it fails. Assert takes a conditional expression and a string - it print the string if the expression evaluate to false.

if(!some_condition_that_should_always_be_true){
    console.log("Something is not right");
}

//Could be better written
console.assert(some_condition_that_should_always_be_true, "Something is not right")

Console.count
Some other time we just want to count how many time something happen during our code's execution. A cumbersome way of doing that is to print something with console.log each time the thing we want to track happen then filter our logs to manually count the occurrence. That approach has a lot of issues - the first being that you have to manually count the occurrence (in 2024, that's unthinkable); second you have to filter your logs which prevent you from looking at other log output while counting. The solution is console.count .  

let a = 0

if(something_happended_to_a){
    a++;
    console.count("Inc A");
}
if(something_else_happend_to_a){
    a++;
    console.count("Inc A");
}
if(again_something_happend_to_a){
    a++;
    console.count("Inc A");
}

Console.count returns the number of time it has been called with a particular label. In this snippet we have the label "Inc A" that has been used 3 times.

Console.time
Another common use case of console.log is to time calculate the execution time of a code block. Usually it is done by having a constant declared at the beginning of the block that holds the  timestamp then declaring another constant that hold the timestamp at the end, then we can console.log the difference between the two timestamp. This is cumbersome and we are declaring boilerplate code into our code base. The solution is console.time and console.timeEnd.

//This is the block for which we want to calculate the execution time
console.time("myTimerLabel");
someComplexStuff();
moreComplexStuff();
console.timeEnd("myTimerLabel");

Our timer start when we call console.time and ends when we call console.timeEnd in the console it prints the label that we used followed by the time that has passed between the two calls.