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

This article mainly introduces the relevant knowledge of "collaborative process case analysis in java collaborative process framework quasar and kotlin". The editor shows you the operation process through the actual case, the operation method is simple, fast and practical. I hope this article "collaborative process case analysis in java collaborative framework quasar and kotlin" can help you solve the problem.

Preface

I have long heard that services developed in the Go language can easily achieve millions of levels of qps without any architectural optimization. This benefits from the efficiency of Go language-level co-programming. Different from threads, threads are operating system-level resources, creating threads, scheduling threads, and destroying threads are all weight-level operations. And the resources of threads are limited, so a large number of unlimited creation threads in java can easily bring down the system. The open source project to be shared next solves the dilemma that java can only use the multithreading model to develop highly concurrent applications, and enables java to use the semantics of collaborative programs like the Go language.

Quick experience adding dependency co.paralleluniverse quasar-core 0.7.10

Note: currently, the highest version of quasar is 0.8.0, but the highest version only supports jdk11 or above.

Add java agent

The implementation principle of quasar is that before java loads class, the instrument mechanism of jdk uses asm to modify the bytecode of the target class. It marks the position of the start and end of the co-program code, as well as the location where the method needs to be paused. Each cooperative task is scheduled by FiberScheduler, and one or more ForkJoinPool instances are maintained internally. Therefore, before running the application, you need to configure the java agent address of quasar-core and add the following script to the vm parameter:

-javaagent:D:\ .m2\ repository\ co\ paralleluniverse\ quasar-core\ 0.7.10\ quasar-core-0.7.10.jar thread VS protocol

The following simulation invokes a remote service, assuming that the remote service processing takes 1s. Here, execution blocking 1s is used to simulate. Look at the time required for 10000 calls to this service by the multithreading model and the co-programming model, respectively.

The protocol code public static void main (String [] args) throws Exception {CountDownLatch count = new CountDownLatch (10000); StopWatch stopWatch = new StopWatch (); stopWatch.start (); IntStream.range (010.000) .forEach (I-> new Fiber () {@ Override protected String run () throws SuspendExecution, InterruptedException {Strand.sleep (1000); count.countDown () Return "aa";}}. Start (); count.await (); stopWatch.stop (); System.out.println ("over:" + stopWatch.prettyPrint ());}

Time-consuming situation:

Multithreaded code public static void main (String [] args) throws Exception {CountDownLatch count = new CountDownLatch (10000); StopWatch stopWatch = new StopWatch (); stopWatch.start (); ExecutorService executorService = Executors.newCachedThreadPool (); IntStream.range (0m10000) .forEach (I-> executorService.submit (())-> {try {TimeUnit.SECONDS.sleep (1)) } catch (InterruptedException ex) {} count.countDown ();}); count.await (); stopWatch.stop (); System.out.println ("over:" + stopWatch.prettyPrint ());}

Time-consuming situation

The cooperation is a complete victory.

As you can see from the above results, when accessing a service that takes 1 second for 10000 times, the collaborative process only takes more than 2 seconds, while the multi-threaded model takes more than 4 seconds, which is twice the time difference. And the above multithreaded programming, does not specify the size of the thread pool, in the actual development is not allowed. In general, we will set a fixed size thread pool, because thread resources are precious, thread more memory will also bring thread switching overhead. The above scenario is when setting up 200 fixed-size thread pools. The result is also predictable for more than 50 seconds. This result is enough to prove that co-programming ko thread programming. And the larger the qps, the greater the gap between threading efficiency and collaboration, and the only way to narrow the gap is to increase the number of threads, and the impact is a surge in memory consumption. On the other hand, based on fixed thread scheduling, millions of levels of cooperative processing can be easily achieved, and the memory is stable.

Postscript

Finally, the blogger thought that Quasar was just a framework-level thing, so he took a look at the collaboration of kotlin, which is also in jvm. His language is more concise and can be used directly with java. It only takes more than a second to run the above example.

Fun main () {val count = CountDownLatch (10000) val stopWatch = StopWatch () stopWatch.start () IntStream.range (010000). ForEach {GlobalScope.launch {delay (1000L) println (Thread.currentThread (). Name + ">" + it) count.countDown ()} count.await () stopWatch.stop () println (") It's over: "+ stopWatch.prettyPrint ())}

When the blogger saw this result, he was shocked. Kotlin's synchronization model was so powerful that he instantly felt that he had discovered the slutty behavior in java. He could use kotlin's co-program instead of multithreading in java. Because there is no pressure for the two of them to develop together. If it works, it will be great. So there is the following code for the kotlin protocol implementation:

@ Serviceclass KotlinAsyncService (privateval weatherService: GetWeatherService Privateval demoApplication: DemoApplication) {val weatherUrl = "http://localhost:8080/demo/mockWeatherApi?city=" fun getHuNanWeather (): JSONObject {val result = JSONObject () val count = CountDownLatch (demoApplication.weatherContext.size) for (city in demoApplication.weatherContext) {val url = weatherUrl + city.key GlobalScope.launch {result [city.key.toString ()] = weatherService.get (url) ) count.countDown ()}} count.await () return result}}

The reality is that when I use the co-program to replace the interface where a multi-thread aggregates the results of multiple http interfaces written by my java multithread, the performance of the two of them does not change much through the ab stress test. Finally, I learned that the main reason is that at this time, when initiating a http request in the protocol, it involves the socket io operation at the operating system level, and the io operation is blocked. The concurrency of the co-program becomes the concurrency of several threads scheduling the co-program. And when I put the same code in Quasar, Quasar directly throws an io exception, indicating that Quasar does not easily support this scenario. So why is there such a big gap in the above test results? it is because I mistakenly equate the blocking in the implementation of the co-program with the blocking of the thread. The delay suspend function in the co-program immediately releases the thread to the thread pool, but when the real io blocks, it is the same as the real thread sleep, and does not release the current thread. So these comparisons don't make much sense.

This is the end of the content of "instance Analysis of java collaboration in quasar and kotlin". Thank you for your reading. If you want to know more about the industry, you can follow the industry information channel. The editor will update different knowledge points for you every day.

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.