Skip to main content

About virtual thread in java

In this blog post, I will introduce you to the concept of virtual threads in Java and how they can improve the performance and scalability of your applications that rely on networking I/O.

Virtual threads are lightweight threads that reduce the effort of writing, maintaining, and debugging high-throughput concurrent applications. They are instances of java.lang.Thread that are not tied to a specific operating system (OS) thread, but rather run on a small number of OS threads managed by the Java runtime. This allows the Java runtime to suspend and resume virtual threads when they perform blocking I/O operations, freeing up the OS threads for other tasks. Virtual threads typically have a shallow call stack and perform as few as a single HTTP client call or a single JDBC query. They are suitable for tasks that spend most of their time waiting for I/O, but not for long-running CPU-intensive tasks.

Virtual threads are supported by the Java Platform since Java SE 21. They are part of Project Loom, which aims to simplify concurrent programming in Java by providing new APIs and features for concurrency and parallelism. You can read more about the background and motivation of Project Loom in JEP 444.

To create a virtual thread, you can use the Thread.ofVirtual() method, which returns an instance of Thread.Builder that can be used to configure and start the virtual thread. For example:

Alternatively, you can use the Executors.newVirtualThreadExecutor() method, which returns an ExecutorService that creates a new virtual thread for each submitted task. For example:

 java

Thread virtualThread = Thread.ofVirtual().start(() -> {

    // Code to be executed by the virtual thread

});

Comments

Popular posts from this blog

is not a JMX compliant Standard MBean

I got the fallowing exception and issue solved. If your are using MBean , MBean Interface and Implementation should be in same package, Otherwise use MXBean. javax.management.NotCompliantMBeanException: MBean class comlanka.rest.controller.DataManagerController does not implement DynamicMBean, and neither follows the Standard MBean conventions (javax.management.NotCompliantMBeanException: Class comlanka.rest.controller.DataManagerController is not a JMX compliant Standard MBean) nor the MXBean conventions (javax.management.NotCompliantMBeanException: comlanka.rest.controller.DataManagerController: Class comlanka.rest.controller.DataManagerController is not a JMX compliant MXBean)         at com.sun.jmx.mbeanserver.Introspector.checkCompliance(Introspector.java:176)         at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:317)         at com.sun.jmx.mbeanserver.Jmx...

AWS amplify hugo App build specification amplify.yml

 I needed a content-oriented site with solely static content for a little project I'm working on, so Hugo was an obvious choice. I looked into using AWS Amplify to host it, But the default amplify.yml not working for me and can't find the correct build file, I have modified the amplify.yml to build the Hugo cms. Hope this is helpful, Please comment. version : 1 frontend : phases : build : commands : - npm install - npm run build:webpack && npm run build:hugo artifacts : baseDirectory : dist files : - '**/*' cache : paths : []

hamcrest and junit java.lang.NoSuchFieldError: NONE

Issue - When you using hemcrest with JUnit5 you may get  java.lang.NoSuchFieldError: NONE error. Solution - Add junit-vintage-engine to classpath           <dependency>             <groupId>org.junit.vintage</groupId>             <artifactId>junit-vintage-engine</artifactId>             <version>5.3.1</version>             <scope>test</scope>         </dependency>  Full Exception - java.lang.NoSuchFieldError: NONE at org.hamcrest.DiagnosingMatcher.matches(DiagnosingMatcher.java:12) at org.hamcrest.beans.SamePropertyValuesAs.hasMatchingValues(SamePropertyValuesAs.java:63) at org.hamcrest.beans.SamePropertyValuesAs.matchesSafely(SamePropertyValuesAs.java:31) at org.hamcrest.TypeSafeDiagnosingMatcher.matches(TypeSafeDiagnosing...