refactor: improving correctness of javadocs

Author: alxkm

src/main/java/org/alxkm/antipatterns/forgottensynchronization/CounterExample.java

@@ -1,6 +1,6 @@
 package org.alxkm.antipatterns.forgottensynchronization;
 
-/***
+/**
  *
  * Forgotten synchronization is a common concurrency issue in Java where a method or block of code that should be synchronized is not,
  * potentially leading to inconsistent data states or race conditions. Here's an example demonstrating this problem along with a resolution.
@@ -9,7 +9,7 @@
  * In this example, the increment method and the getCount method are not synchronized,
  * leading to potential race conditions when accessed by multiple threads simultaneously.
  *
- * */
+ */
 public class CounterExample {
     private int counter = 0;
 

src/main/java/org/alxkm/antipatterns/forgottensynchronization/CounterReentrantLockResolution.java

@@ -3,12 +3,12 @@
 import java.util.concurrent.locks.Lock;
 import java.util.concurrent.locks.ReentrantLock;
 
-/***
+/**
  * Instead of using the synchronized keyword, we can use ReentrantLock for more advanced synchronization control.
  *
  * Using ReentrantLock provides more flexibility and control over the synchronization process,
  * including the ability to use tryLock, lockInterruptibly, and other features not available with the synchronized keyword.
- * */
+ */
 public class CounterReentrantLockResolution {
     private int count = 0;
     private final Lock lock = new ReentrantLock();

src/main/java/org/alxkm/antipatterns/forgottensynchronization/CounterSynchronized.java

@@ -1,10 +1,10 @@
 package org.alxkm.antipatterns.forgottensynchronization;
 
-/***
+/**
  *
  * To resolve this issue, we need to synchronize the methods to ensure that only one thread can access these critical sections at a time.
  *
- * */
+ */
 public class CounterSynchronized {
     private int counter = 0;
 

src/main/java/org/alxkm/antipatterns/ignoringinterruptedexception/ProperlyHandlingInterruptedException.java

@@ -4,12 +4,11 @@
  *
  * To resolve this issue, the thread should properly handle InterruptedException by either propagating the exception or breaking out of the loop.
  *
- *
  * In this revised example, the run method handles the
  * InterruptedException by restoring the interrupt status with Thread.currentThread().interrupt() and breaking out of the loop.
  * This ensures that the thread stops running as intended.
  *
- * */
+ */
 public class ProperlyHandlingInterruptedException implements Runnable {
     /**
      * The run method performs a long-running task.

src/main/java/org/alxkm/antipatterns/improperuseofthreadlocal/ThreadLocalExample.java

@@ -10,7 +10,7 @@
  * However, the values are not removed after usage, which can lead to memory leaks,
  * especially in environments where threads are reused, such as in thread pools.
  *
- * */
+ */
 public class ThreadLocalExample {
     private static final ThreadLocal<String> THREAD_LOCAL = new ThreadLocal<>();
 

src/main/java/org/alxkm/antipatterns/lackofthreadsafetyinsingletons/DoubleCheckedLockingSingleton.java

@@ -7,7 +7,7 @@
  * In this version, the volatile keyword ensures visibility of changes to the instance variable across threads,
  * while double-checked locking minimizes synchronization overhead.
  *
- * */
+ */
 public class DoubleCheckedLockingSingleton {
     private static volatile DoubleCheckedLockingSingleton instance;
 

src/main/java/org/alxkm/antipatterns/lackofthreadsafetyinsingletons/SafeSingleton.java

@@ -7,7 +7,7 @@
  * In this revised example, the getInstance method is synchronized,
  * ensuring that only one instance is created even when multiple threads access the method simultaneously.
  *
- * */
+ */
 public class SafeSingleton {
     private static SafeSingleton instance;
 

src/main/java/org/alxkm/antipatterns/lockcontention/LockContentionExample.java

@@ -1,6 +1,7 @@
 package org.alxkm.antipatterns.lockcontention;
 
 /**
+ *
  * Lock contention occurs when multiple threads compete for the same lock, causing some threads to wait while another thread holds the lock.
  * This can lead to reduced performance due to increased waiting times and underutilized CPU resources.
  *

src/main/java/org/alxkm/antipatterns/lockcontention/LockContentionResolution.java

@@ -9,7 +9,7 @@
  * In this revised example, we use AtomicInteger to manage the counter.
  * AtomicInteger provides thread-safe operations without the need for explicit synchronization, significantly reducing lock contention.
  *
- * */
+ */
 public class LockContentionResolution {
     private final AtomicInteger counter = new AtomicInteger();
 

src/main/java/org/alxkm/antipatterns/lockcontention/StampedLockExample.java

@@ -9,7 +9,7 @@
  * In this version, StampedLock is used to manage the counter.
  * StampedLock allows for optimistic reads, which can improve performance by avoiding locks if the data hasn't changed.
  *
- * */
+ */
 public class StampedLockExample {
     private final StampedLock lock = new StampedLock();
     private int counter = 0;

src/main/java/org/alxkm/antipatterns/nonatomiccompoundactions/AtomicCompoundActionsExample.java

@@ -8,7 +8,7 @@
  * ensuring that the compound action is performed atomically.
  * This prevents race conditions and ensures correct results.
  *
- * */
+ */
 public class AtomicCompoundActionsExample {
     private int counter = 0;
 

src/main/java/org/alxkm/antipatterns/nonatomiccompoundactions/AtomicIntegerExample.java

@@ -3,6 +3,7 @@
 import java.util.concurrent.atomic.AtomicInteger;
 
 /**
+ *
  * Another approach is to use the atomic classes provided by the java.util.concurrent package,
  * such as AtomicInteger, which provides atomic operations for integers.
  * <p>

src/main/java/org/alxkm/antipatterns/startingthreadinconstructor/ThreadStartedOutsideConstructor.java

@@ -1,14 +1,14 @@
 package org.alxkm.antipatterns.startingthreadinconstructor;
 
-/***
+/**
  *
  * To resolve this issue, start the thread outside the constructor,
  * ensuring that the object is fully constructed before the thread starts.
  *
  * In this revised example, the thread is created in the main method after the object is fully constructed,
  * ensuring that the thread starts at an appropriate time.
  *
- * */
+ */
 public class ThreadStartedOutsideConstructor extends Thread {
     private final String message;
 

src/main/java/org/alxkm/antipatterns/startingthreadinconstructor/ThreadUsingFactory.java

@@ -1,6 +1,6 @@
 package org.alxkm.antipatterns.startingthreadinconstructor;
 
-/***
+/**
  *
  * Another approach is to use factory methods to create and start the thread,
  * ensuring separation of concerns and better control over the thread lifecycle.
@@ -9,7 +9,7 @@
  * and a factory method createAndStart to create and start the thread.
  * This ensures that the thread starts at an appropriate time and provides better encapsulation of the thread creation logic.
  *
- * */
+ */
 public class ThreadUsingFactory {
     private final String message;
 

src/main/java/org/alxkm/antipatterns/usingthreadsafecollectionsincorrectly/CorrectUsage.java

@@ -10,7 +10,7 @@
  *
  * By synchronizing the addIfAbsent method, we ensure that only one thread can execute it at a time, making the operation atomic.
  *
- * */
+ */
 public class CorrectUsage implements BaseListUsage<String> {
     private final List<String> list = new CopyOnWriteArrayList<>();
 

src/main/java/org/alxkm/patterns/atomics/AtomicReferenceExample.java

@@ -36,7 +36,7 @@ public void setData(String data) {
      * Both threads run concurrently.
      * After both threads have completed, the main thread prints the final state of the shared resource.
      *
-     * */
+     */
     public static void main(String[] args) {
         SharedResource initialResource = new SharedResource("Initial Data");
         AtomicReference<SharedResource> atomicReference = new AtomicReference<>(initialResource);

src/main/java/org/alxkm/patterns/executors/ScheduledThreadPoolExecutorExample.java

@@ -17,7 +17,7 @@ public class ScheduledThreadPoolExecutorExample {
      * Task 3: Executes repeatedly with a fixed delay between termination of one execution and commencement of the next, starting after an initial delay of 2 seconds, with a delay of 3 seconds using scheduleWithFixedDelay().
      * Finally, we schedule a task to shut down the executor after 10 seconds using schedule().
      *
-     * */
+     */
     public static void main(String[] args) {
         // Create a ScheduledThreadPoolExecutor with 3 threads
         ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(3);

src/main/java/org/alxkm/patterns/queue/ConcurrentLinkedQueueExample.java

@@ -6,7 +6,7 @@
  * Demonstrates the usage of ConcurrentLinkedQueue in a multithreaded environment.
  */
 public class ConcurrentLinkedQueueExample {
-    /***
+    /**
      *
      * We create a ConcurrentLinkedQueue named queue.
      * We define two producer threads (producer1 and producer2) that add elements to the queue using the offer() method.
@@ -16,7 +16,7 @@ public class ConcurrentLinkedQueueExample {
      * We start all producer and consumer threads concurrently.
      * As elements are added and removed from the queue, the producer and consumer threads print messages indicating the elements they add or remove.
      *
-     * */
+     */
     public static void main(String[] args) {
         // Create a ConcurrentLinkedQueue
         ConcurrentLinkedQueue<Integer> queue = new ConcurrentLinkedQueue<>();