Shulou(Shulou.com)06/02 Report--

Java high concurrency thread unsafe classes and writing methods, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

What is a thread unsafe class?

If the objects of a class can be accessed by multiple threads at the same time, if there is no special synchronization and concurrency processing, it is easy to show thread unsafe phenomena, such as throwing exceptions, such as logic processing errors, and so on. This class is a thread-unsafe class.

StringBuilder- > StringBuffer@Slf4jpublic class StringExample1 {/ / Total number of requests public static int clientTotal = 5000; / / number of threads executing concurrently public static int threadTotal = 200; public static StringBuilder stringBuilder = new StringBuilder (); public static void main (String [] args) throws InterruptedException {/ / thread pool ExecutorService executorService = Executors.newCachedThreadPool (); / / define semaphore final Semaphore semaphore = new Semaphore (threadTotal) / / define counter final CountDownLatch countDownLatch = new CountDownLatch (clientTotal); for (int I = 0; I

< clientTotal; i++) { executorService.execute(() ->

{try {semaphore.acquire (); update (); semaphore.release ();} catch (InterruptedException e) {log.error ("exception", e);} countDownLatch.countDown ();}) } countDownLatch.await (); executorService.shutdown (); log.info ("size: {}", stringBuilder.length ());} public static void update () {stringBuilder.append ("1");}}

The output is not consistent with our expectations. StringBuilder is a thread-unsafe class.

If we replace StringBuilder with StringBuffer, we can get the desired results. Indicates that StringBuffer is thread-safe.

Look at the append method of StringBuffer and find that this method is preceded by the synchronized keyword with other methods.

Because StringBuffer uses the synchronized keyword, there will be performance loss when using it, so when doing string concatenation, you can consider StringBuffer when doing string concatenation.

But most of the time, we often do string concatenation alone in a method and define a StringBuilder variable. Because defining local variables inside a method is stack-closed, only a single thread can manipulate the object, and thread safety is not involved.

SimpleDateFormat-> JodaTime@Slf4jpublic class DateFormatExample1 {private static SimpleDateFormat simpleDateFormat = new SimpleDateFormat ("yyyyMMdd"); / / Total number of requests public static int clientTotal = 5000; / / number of threads executing concurrently public static int threadTotal = 200; public static void main (String [] args) throws InterruptedException {/ / thread pool ExecutorService executorService = Executors.newCachedThreadPool (); / / define semaphore final Semaphore semaphore = new Semaphore (threadTotal) / / define counter final CountDownLatch countDownLatch = new CountDownLatch (clientTotal); for (int I = 0; I

< clientTotal; i++) { executorService.execute(() ->

{try {semaphore.acquire (); update (); semaphore.release ();} catch (InterruptedException e) {log.error ("exception", e);} countDownLatch.countDown ();}) } countDownLatch.await (); executorService.shutdown ();} public static void update () {try {simpleDateFormat.parse ("20190729");} catch (ParseException e) {e.printStackTrace (); log.error ("parse Exception" + e);}

At run time, an exception is thrown:

Exception in thread "pool-1-thread-3" java.lang.NumberFormatException: For input string: "E.177" at sun.misc.FloatingDecimal.readJavaFormatString (FloatingDecimal.java:2043) at sun.misc.FloatingDecimal.parseDouble (FloatingDecimal.java:110) at java.lang.Double.parseDouble (Double.java:538) at java.text.DigitList.getDouble (DigitList.java:169) at java.text.DecimalFormat.parse : 2056) at java.text.SimpleDateFormat.subParse (SimpleDateFormat.java:1867) at java.text.SimpleDateFormat.parse (SimpleDateFormat.java:1514) at java.text.DateFormat.parse (DateFormat.java:364) at com.vincent.example.commonUnsafe.DateFormatExample1.update (DateFormatExample1.java:50) at com.vincent.example.commonUnsafe.DateFormatExample1.lambda$main$0 (DateFormatExample1.java:34) at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:617) at java.lang.Thread.run (Thread.java:745)

This is not thread-safe. SimpleDateFormat is not a thread-safe class. One solution is to put SimpleDateFormat simpleDateFormat = new SimpleDateFormat () in the method, close the stack, and modify the update method as follows:

Public static void update () {try {SimpleDateFormat simpleDateFormat = new SimpleDateFormat ("yyyyMMdd"); simpleDateFormat.parse ("20190729");} catch (ParseException e) {e.printStackTrace (); log.error ("parse Exception" + e);}}

JodaTime is thread-safe:

@ Slf4j@ThreadSafepublic class DateFormatExample3 {/ / Total number of requests public static int clientTotal = 5000; / / number of threads executing concurrently public static int threadTotal = 200; private static DateTimeFormatter dateTimeFormatter = DateTimeFormat.forPattern ("yyyyMMdd"); public static void main (String [] args) throws InterruptedException {/ / thread pool ExecutorService executorService = Executors.newCachedThreadPool (); / / define semaphore final Semaphore semaphore = new Semaphore (threadTotal) / / define counter final CountDownLatch countDownLatch = new CountDownLatch (clientTotal); for (int I = 0; I

< clientTotal; i++) { final int count = i; executorService.execute(() ->

{try {semaphore.acquire (); update (count); semaphore.release ();} catch (InterruptedException e) {log.error ("exception", e);} countDownLatch.countDown ();}) } countDownLatch.await (); executorService.shutdown ();} public static void update (int I) {log.info ("{}, {}", I, DateTime.parse ("20190729", dateTimeFormatter). ToDate ();}} ArrayList,HashSet,HashMap and other Collections

Usually when we use these collection classes, their objects are usually declared as local variables in the method, rarely trigger thread unsafe problems, but once defined as static and multiple threads can be modified, there will be a container problem. For example, the following code:

@ Slf4jpublic class ArrayListExample {/ / Total number of requests public static int clientTotal = 5000; / / number of threads executing concurrently public static int threadTotal = 200; private static List list = new ArrayList (); public static void main (String [] args) throws InterruptedException {/ / thread pool ExecutorService executorService = Executors.newCachedThreadPool (); / / define semaphore final Semaphore semaphore = new Semaphore (threadTotal) / / define counter final CountDownLatch countDownLatch = new CountDownLatch (clientTotal); for (int I = 0; I

< clientTotal; i++) { final int count = i; executorService.execute(() ->

{try {semaphore.acquire (); update (count); semaphore.release ();} catch (InterruptedException e) {log.error ("exception", e);} countDownLatch.countDown ();}) } countDownLatch.await (); executorService.shutdown (); log.info ("size: {}", list.size ());} public static void update (int I) {list.add (I);}}

The output is not what we expected.

The same applies to HashSet,HashMap and does not output correct results. These are not thread-safe.

The thread-safe classes corresponding to these collections are described later.

First check the execution of if (condition (a)) {handle (a);}

Why is this writing not thread-safe? Suppose an is a thread-safe class, and even if if (condition (a)) is a thread-safe operation, handle (a) is thread-safe, but the combination of the two is not thread-safe and atomic.

When the Atomic class is self-increasing, the underlying implementation is based on the CAS principle to ensure that the atomicity is new.

In the actual process, if you encounter this situation to judge whether an object meets a certain condition, and then do an operation, you must first consider whether the object is shared by multiple threads, and if it is shared by multiple threads, you must put a lock on it. or make sure the operation is atomic. Otherwise, it will trigger thread unsafe.

After reading the above, have you mastered the methods of thread unsafe classes and writing in java high concurrency? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.