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;