How does JVM map a Java thread to a native thread

Java线程与操作系统线程映射原理及现代多核处理器下编程挑战
本文深入探讨了Java线程如何通过Java Native Interface (JNI)与操作系统线程进行映射,以及多核处理器环境下语言设计和实现如何受到线程调度和管理的影响。重点分析了Java虚拟机(JVM)如何配置多核处理器上的Linux操作系统,确保Java线程与OS线程高效执行,并讨论了Linux内核中任务管理和调度的实现,包括完全公平调度器(CFS)等关键概念。

原文链接:http://narmnevis.com/tag/pthreads/

I’ve been recently studying about programming language design on multicore platforms. To design such a language, studying other platforms such as Java or C++ helps understand concepts better. There are a few questions interesting to have answers for:

  1. How does JVM maps a Java thread to a native thread to be executed in the underlying operating system?
  2. How is language design and implementation affected by thread scheduling and management in accordance with the operating system?

Starting with the first one, Java threads actually have two faces. One is the one that is seen in the Java programming language and used by the programmer. The other is the native implementation that is provided by Java language and managed by JVM. Java introduces JNI [1]: Java Native Interface. Through JNI, a programmer can have a class that is partly written in Java and partly written in some other language such as C++. JNI is used to implement parts of Java Thread class in C++. This implementation declares the methods and services required in Java Thread features but not implemented in Java itself.

While JNI brings in some of the implementation of Java Thread into C++, source implementation of JDK shows that there is also an abstraction of threads that are completely written in C++ providing the functionality required to work with threads. This abstraction is used by a JVM instance. As JVM is implemented in a platform-specific approach, each platform provides a set of API and libraries to work with OS threads.Thus, the abstraction is used by JVM to bridge the Java Thread model to an OS-specific model to be executed. For the same reason, a JVM implementation comes with a platform-specific source that will handle different settings regarding CPU and OS variations. For instance, there is a `linux_os_cpu.cpp` source file in the JVM that denotes that implementation is specific for a Linux-based operating system dealing with CPU requirements.

So, let’s the configuration to a multicore processor on a Linux-based operating system having a relevant JVM implementation. On one level, a JVM instance will handle a Java Thread and converts it into an OS native thread that will be executed. On another level, Linux provides a high-level abstraction of threads to be used by different applications. The modern library that handles this is called Native POSIX Thread Library (NPTL) [2] that is a C++ library to enable the Linux kernel to run threads that are written based on POSIX Thread Standard (PThreads) [3]. Thus, JVM implementation actually takes advantage of a PThreads implementation called NPTL and maps a Java Thread to an instance of thread that will be understandable and executable by the Linux kernel.

Speaking about the kernel, the Linux kernel understands some scheduled entity called task that will be managed and executed according to the algorithm  used in the kernel. So here, we have a problem of mapping an application thread to a kernel schedulable entity. There are three models that can be discussed: kernel-level threading (1:1), user-level threading (N:1), and hybrid threading (N:M) [4]. In kernel-level threading, each thread in the application and user space is converted to exactly one scheduled entity in the kernel space. In user-level threading, all threads in an application are mapped to only one thread in the kernel space. Hybrid threading is a mixture of both. Browsing through OS implementation history, it reveals that most implementations have converged to 1:1 model since it utilizes the processing power and relieves the task of scheduling from the languages and libraries. Also, it is argued that implementing N:M model will be costly while complex  and also usually operating system implementation will provide better and optimized services such as scheduling and context switching. Linux kernel uses a 1:1 mapping model. Since JVM only maps a Java Thread to a native OS thread, JVM is also following 1:1 model. So, if a Java program is written in a way to utilize several processors, it is guarantees that the Linux kernel will maximize the simultaneous use of different core as much as possible. Since Java 1.2+, JVM put aside the concepts of Green Threads [5] and used instead the native thread features to map Java Thread to native operating system threads.

Through the discussion, we mentioned the scheduling of kernel entities for execution (tasks). As of Linux kernel 2.6.23+, they have implemented a scheduler algorithm called Completely Fair Scheduler (CFS) [6]. CFS will optimize the most important scheduling workload to O(1) [7]. Also, it has a feature that will check for load balancing the work load among the processors and redistributes the work if necessary [7].So, this way the reason not to go to N:M model gets even more strengthen as the Linux kernel features promise more while efficient. On the other hand, when a process is created it will hold a number of threads of execution. Each process, and its child threads, will be given a Processor Affinity [8] that is a simple map to show that how much this process (thread) is likely to be executed on a specific core among the processors. This is done to minimize the costs in case some thread is being reactivated in the same core and some of its data is present nearby.

To conclude, as the native operating systems on multicore is doing pretty well in terms of abstraction and performance, it is worth to consider such facts when designing and implementing a language that aims the challenges of programming on multicore platforms. Since the mapping of application threads to kernel threads are handled in a neat way, maybe it would not be wise to meddle with the such problems in the language design.

Accordingly, I also posted two questions ([9] and [10]) on Stackoverflow.com and received good answers.

  1. [1]: http://en.wikipedia.org/wiki/Java_Native_Interface
  2. [2]: http://en.wikipedia.org/wiki/Native_POSIX_Thread_Library
  3. [3]: http://en.wikipedia.org/wiki/POSIX_Threads
  4. [4]: http://en.wikipedia.org/wiki/Thread_%28computer_science%29#Models
  5. [5]: http://en.wikipedia.org/wiki/Green_threads
  6. [6]: http://en.wikipedia.org/wiki/Completely_Fair_Scheduler
  7. [7]: http://www.ibm.com/developerworks/linux/library/l-scheduler/
  8. [8]: http://en.wikipedia.org/wiki/Processor_affinity
  9. [9]: http://stackoverflow.com/questions/4203021/jvm-implementation-of-thread-work-distribution-and-multicore
  10. [10]: http://stackoverflow.com/questions/4249124/hybrid-thread-model-mn-implementation


Your feedback is requested on changes under consideration for SLF4J version 2.1.0. SLF4J warning or error messages and their meanings No SLF4J providers were found. This message is a warning and not an error. It is reported when no SLF4J providers could be found on the class path. SLF4J requires a logging provider because it is a logging API and not an logging implementation. Placing one (and only one) of the many available providers such as slf4j-nop.jar slf4j-simple.jar, slf4j-reload4j.jar, slf4j-jdk14.jar or logback-classic.jar on the class path will solve the problem. In the absence of a provider, SLF4J will default to a no-operation (NOP) logger provider. Please note that slf4j-api version 2.0.x and later use the ServiceLoader mechanism. Earlier versions relied on the static binder mechanism which is no longer honored by slf4j-api. Please read the FAQ entry What has changed in SLF4J version 2.0.0? for further important details. If you are responsible for packaging an application and do not care about logging, then placing slf4j-nop.jar on the class path of your application will get rid of this warning message. Note that embedded components such as libraries or frameworks should not declare a dependency on any SLF4J providers but only depend on slf4j-api. When a library declares a compile-time dependency on a SLF4J provider, it imposes that provider on the end-user, thus negating SLF4J's purpose. Class path contains SLF4J bindings targeting slf4j-api versions 1.7.x or earlier Planning for the advent of Jigsaw (Java 9), slf4j-api version 2.0.x and later use the ServiceLoader mechanism. Earlier versions of SLF4J relied on the static binder mechanism which is no longer honored by slf4j-api version 2.0.x. In case SLF4J 2.x finds no providers targeting SLF4J 2.x but finds instead bindings targeting SLF4J 1.7 or earlier, it will list the bindings it finds but otherwise will ignore them. This can be solved by placing an SLF4J provider on your classpath, such providers include logback version 1.3.x and later, as well as one of slf4j-reload4j, slf4j-jdk14, slf4j-simple version 2.0.0 or later. See also the FAQ entry What has changed in SLF4J version 2.0.0? for further important details. IllegalStateException: org.slf4j.LoggerFactory in failed state. Original exception was thrown EARLIER. This IllegalStateException is thrown post-initialization and informs the user that initialization of LoggerFactory has failed. Note It is important to realize that the exception causing the failure was thrown at an earlier stage. This earlier exception should provide more valuable information about the root cause of the problem. The method o.a.commons.logging.impl.SLF4FLogFactory#release was invoked. Given the structure of the commons-logging API, in particular as implemented by SLF4J, the o.a.commons.logging.impl.SLF4FLogFactory#release() method should never be called. However, depending on the deployment of commons-logging.jar files in your servlet container, release() method may be unexpectedly invoked by a copy of org.apache.commons.logging.LogFactory class shipping with commons-logging.jar. This is a relatively common occurrence with recent versions of Tomcat, especially if you place jcl-over-slf4j.jar in WEB-INF/lib directory of your web-application instead of $TOMCAT_HOME/common/lib, where $TOMCAT_HOME stands for the directory where Tomcat is installed. In order to fully benefit from the stability offered by jcl-over-slf4j.jar, we recommend that you place jcl-over-slf4j.jar in $TOMCAT_HOME/common/lib without placing a copy in your web-applications. Please also see bug #22. Operation [suchAndSuch] is not supported in jcl-over-slf4j. An UnsupportedOperationException is thrown whenever one of the protected methods introduced in JCL 1.1 are invoked. These methods are invoked by LogFactory implementations shipping with commons-logging.jar. However, the LogFactory implemented by jcl-over-slf4j.jar, namely SLF4FLogFactory, does not call any of these methods. If you observe this problem, then it is highly probable that you have a copy of commons-logging.jar in your class path overriding the classes shipping with jcl-over-slf4j.jar. Note that this issue is very similar in nature to the warning issued when the "o.a.commons.logging.impl.SLF4FLogFactory.release()" method is invoked, discussed in the previous item. Detected logger name mismatch Logger name mismatch warnings are printed only if the slf4j.detectLoggerNameMismatch system property is set to true. By default, this property is not set and no warnings will be printed even in case of a logger name mismatch. since 1.7.9 The warning will be printed in case the name of the logger specified via a class passed as an argument to the LoggerFactory.getLogger(Class) method differs from the name of the caller as computed internally by SLF4J. For example, the following code snippet package com.acme; import com.foo.Kangaroo; class Fruit { Logger logger = LoggerFactory.getLogger(Kangaroo.class); } will result in the warning SLF4J: Detected logger name mismatch. Given name: "com.foo.Kangaroo"; computed name: "com.acme.Fruit". but only if slf4j.detectLoggerNameMismatch system property is set to true. No warning will be issued for the special case where the class in which the logger is defined is a super-type of the class parameter passed as argument. For example, class A { Logger logger = LoggerFactory.getLogger(getClass()); } class B extends A { // no mismatch warning will be issued when B is instantiated // given that class A is a super-type of class B } If you come across a mismatch warning which cannot be explained, then you might have spotted a white elephant, that is a very rare occurrence where SLF4J cannot correctly compute the name of the class where a logger is defined. We are very interested to learn about such cases. If and when you spot an inexplicable mismatch, please do file a bug report with us. Failed to load class org.slf4j.impl.StaticLoggerBinder This warning message is reported by slf4j-api version 1.7.x and earlier when the org.slf4j.impl.StaticLoggerBinder class could not be loaded into memory. This happens when no appropriate SLF4J binding could be found on the class path. Placing one (and only one) of slf4j-nop.jar slf4j-simple.jar, slf4j-log4j12.jar, slf4j-jdk14.jar or logback-classic.jar on the class path should solve the problem. If you are seeing this message, then you are NOT using slf4j-api version 2.0 or later but slf4j-api version 1.7.x or earlier. Slf4j-api versions 2.0.x and later use the ServiceLoader mechanism. Backends such as logback 1.3 and later which target slf4j-api 2.x, do not ship with org.slf4j.impl.StaticLoggerBinder. If you place a logging backend which targets slf4j-api 2.0.x, you need slf4j-api-2.x.jar on the classpath. See also relevant faq entry. since 1.6.0 As of SLF4J version 1.6, in the absence of a binding, SLF4J will default to a no-operation (NOP) logger implementation. If you are responsible for packaging an application and do not care about logging, then placing slf4j-nop.jar on the class path of your application will get rid of this warning message. Note that embedded components such as libraries or frameworks should not declare a dependency on any SLF4J binding (or provider) but only depend on slf4j-api. When a library declares a compile-time dependency on a SLF4J binding (or provider), it imposes that binding (or provider) on the end-user, thus negating SLF4J's purpose. Multiple bindings were found on the class path SLF4J API is designed to bind with one and only one underlying logging framework at a time. If more than one binding is present on the class path, SLF4J will emit a warning, listing the location of those bindings. When multiple bindings are available on the class path, select one and only one binding you wish to use, and remove the other bindings. For example, if you have both slf4j-simple-2.0.17.jar and slf4j-nop-2.0.17.jar on the class path and you wish to use the nop (no-operation) binding, then remove slf4j-simple-2.0.17.jar from the class path. The list of locations that SLF4J provides in this warning usually provides sufficient information to identify the dependency transitively pulling in an unwanted SLF4J binding into your project. In your project's pom.xml file, exclude this SLF4J binding when declaring the unscrupulous dependency. For example, cassandra-all version 0.8.1 declares both log4j and slf4j-log4j12 as compile-time dependencies. Thus, when you include cassandra-all as a dependency in your project, the cassandra-all declaration will cause both slf4j-log4j12.jar and log4j.jar to be pulled in as dependencies. In case you do not wish to use log4j as the SLF4J backend, you can instruct Maven to exclude these two artifacts as shown next: <dependencies> <dependency> <groupId> org.apache.cassandra</groupId> <artifactId>cassandra-all</artifactId> <version>0.8.1</version> <exclusions> <exclusion> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> </exclusion> <exclusion> <groupId>log4j</groupId> <artifactId>log4j</artifactId> </exclusion> </exclusions> </dependency> </dependencies> Note The warning emitted by SLF4J is just that, a warning. Even when multiple bindings are present, SLF4J will pick one logging framework/implementation and bind with it. The way SLF4J picks a binding is determined by the JVM and for all practical purposes should be considered random. As of version 1.6.6, SLF4J will name the framework/implementation class it is actually bound to. Embedded components such as libraries or frameworks should not declare a dependency on any SLF4J binding but only depend on slf4j-api. When a library declares a compile-time dependency on a SLF4J binding, it imposes that binding on the end-user, thus negating SLF4J's purpose. When you come across an embedded component declaring a compile-time dependency on any SLF4J binding, please take the time to contact the authors of said component/library and kindly ask them to mend their ways. slf4j-api version does not match that of the binding An SLF4J binding designates an artifact such as slf4j-jdk14.jar or slf4j-log4j12.jar used to bind slf4j to an underlying logging framework, say, java.util.logging and respectively log4j. Mixing different versions of slf4j-api.jar and SLF4J binding (a.k.a. provider since 2.0.0) can cause problems. For example, if you are using slf4j-api-2.0.17.jar, then you should also use slf4j-simple-2.0.17.jar, using slf4j-simple-1.5.5.jar will not work. Note From the client's perspective all versions of slf4j-api are compatible. Client code compiled with slf4j-api-N.jar will run perfectly fine with slf4j-api-M.jar for any N and M. You only need to ensure that the version of your binding matches that of the slf4j-api.jar. You do not have to worry about the version of slf4j-api.jar used by a given dependency in your project. You can always use any version of slf4j-api.jar, and as long as the version of slf4j-api.jar and its binding match, you should be fine. At initialization time, if SLF4J suspects that there may be an api vs. binding version mismatch problem, it will emit a warning about the suspected mismatch. Logging factory implementation cannot be null This error is reported when the LoggerFactory class could not find an appropriate binding. Placing one (and only one) of slf4j-nop.jar, slf4j-simple.jar, slf4j-log4j12.jar, slf4j-jdk14.jar or logback-classic.jar on the class path should prove to be an effective remedy. Detected both log4j-over-slf4j.jar AND slf4j-reload4j on the class path, preempting StackOverflowError. The purpose of slf4j-reload4j module is to delegate or redirect calls made to an SLF4J logger to log4j/reload4j. The purpose of the log4j-over-slf4j module is to redirect calls made to a log4j logger to SLF4J. If SLF4J is bound withslf4j-reload4j.jar and log4j-over-slf4j.jar is also present on the class path, a StackOverflowError will inevitably occur immediately after the first invocation of an SLF4J or a log4j logger. Here is how the exception might look like: Exception in thread "main" java.lang.StackOverflowError at java.util.Hashtable.containsKey(Hashtable.java:306) at org.apache.log4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:36) at org.apache.log4j.LogManager.getLogger(LogManager.java:39) at org.slf4j.impl.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:73) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:249) at org.apache.log4j.Category.<init>(Category.java:53) at org.apache.log4j.Logger..<init>(Logger.java:35) at org.apache.log4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:39) at org.apache.log4j.LogManager.getLogger(LogManager.java:39) at org.slf4j.impl.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:73) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:249) at org.apache.log4j.Category..<init>(Category.java:53) at org.apache.log4j.Logger..<init>(Logger.java:35) at org.apache.log4j.Log4jLoggerFactory.getLogger(Log4jLoggerFactory.java:39) at org.apache.log4j.LogManager.getLogger(LogManager.java:39) subsequent lines omitted... Since 1.5.11 SLF4J software preempts the inevitable stack overflow error by throwing an exception with details about the actual cause of the problem. This is deemed to be better than leaving the user wondering about the reasons of the StackOverflowError. Note that since reload4j provides the log4j 1.x API, reload4j.jar and log4j-over-slf4j.jar cannot be present simultaneously on your classpath. For more background on this topic see Bridging legacy APIs. Detected both jcl-over-slf4j.jar AND slf4j-jcl.jar on the class path, preempting StackOverflowError. The purpose of slf4j-jcl module is to delegate or redirect calls made to an SLF4J logger to jakarta commons logging (JCL). The purpose of the jcl-over-slf4j module is to redirect calls made to a JCL logger to SLF4J. If SLF4J is bound with slf4j-jcl.jar and jcl-over-slf4j.jar is also present on the class path, then a StackOverflowError will inevitably occur immediately after the first invocation of an SLF4J or a JCL logger. Here is how the exception might look like: Exception in thread "main" java.lang.StackOverflowError at java.lang.String.hashCode(String.java:1482) at java.util.HashMap.get(HashMap.java:300) at org.slf4j.impl.JCLLoggerFactory.getLogger(JCLLoggerFactory.java:67) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:249) at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155) at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:289) at org.slf4j.impl.JCLLoggerFactory.getLogger(JCLLoggerFactory.java:69) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:249) at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155) subsequent lines omitted... Since 1.5.11 SLF4J software preempts the inevitable stack overflow error by throwing an exception with details about the actual cause of the problem. This is deemed to be better than leaving the user wondering about the reasons of the StackOverflowError. For more background on this topic see Bridging legacy APIs. Exception in thread "main" java.lang.NoSuchFieldError: tlm Exception in thread "main" java.lang.NoSuchFieldError: tlm at org.apache.log4j.MDCFriend.fixForJava9(MDCFriend.java:11) at org.slf4j.impl.Log4jMDCAdapter.(Log4jMDCAdapter.java:38) at Main.main(Main.java:5) The NoSuchFieldError is thrown when slf4j-log4j12 attempts to access the 'tlm' package private field in org.apache.log4j.MDC which was specified as being of type java.lang.Object in log4j 1.2.x but was changed to java.lang.ThreadLocal in reload4j. Moreover, such access to package private fields from different modules is not authorized by default in modularized applications in Java 9 and later. To keep a long story short, the NoSuchFieldError can be avoided by using slf4j-reload4j.jar with reload4j.jar. Stated differently, org.slf4j.MDC cannot be used with the slf4j-log4j12.jar and reload4j.jar combination. Update: The issue described above was fixed in reload4j 1.2.21. Although it is still recommended that you use slf4j-reload4j as the preferred adapter for the slf4j/reload4j combination, with reload4j version 1.2.21 and later you can freely mix any version of slf4j-log4j12, if you need to. Failed to load class "org.slf4j.impl.StaticMDCBinder" This error indicates that appropriate SLF4J binding could not be found on the class path. Placing one (and only one) of slf4j-nop.jar, slf4j-simple.jar, slf4j-log4j12.jar, slf4j-jdk14.jar or logback-classic.jar on the class path should solve the problem. MDCAdapter cannot be null This error is reported when org.slf4j.MDC class has not been initialized correctly. Same cause and remedy as the previously listed item. A number (N) of logging calls during the initialization phase have been intercepted and are now being replayed. These are subject to the filtering rules of the underlying logging system. since 1.7.15 Logging calls made during the initialization phase are recorded and replayed post-initialization. Note that the replayed logging calls are subject to filtering by the underlying logging system. In principle, replaying only occurs for applications which are already multithreaded at the time the first logging call occurs. See also substitute loggers. Substitute loggers were created during the default configuration phase of the underlying logging system Highly configurable logging systems such as logback and log4j may create components which invoke loggers during their own initialization. See issue LOGBACK-127 for a typical occurrence. However, since the binding process with SLF4J has not yet completed (because the underlying logging system was not yet completely loaded into memory), it is not possible to honor such logger creation requests. To avoid this chicken-and-egg problem, SLF4J creates substitute loggers during this phase (initialization). Calls made to the substitute loggers during this phase are simply dropped. After the initialization completes, the substitute logger will delegate logging calls to the appropriate logger implementation and otherwise will function as any other logger returned by LoggerFactory. If any substitute logger had to be created, SLF4J will emit a listing of such loggers. This list is intended to let you know that any logging calls made to these loggers during initialization have been dropped. See also intercepted and replayed logging calls. SLF4J versions 1.4.0 and later requires log4j 1.2.12 or later The trace level was added to log4j in version 1.2.12 released on August 29, 2005. The trace level was added to the SLF4J API in version 1.4.0 on May 16th, 2007. Thus, starting with SLF4J 1.4.0, the log4j binding for SLF4J requires log4j version 1.2.12 or above. However, as reported in issue 59, in some environments it may be difficult to upgrade the log4j version. To accommodate such circumstances, SLF4J's Log4jLoggerAdapter will map the TRACE level as DEBUG. java.lang.NoClassDefFoundError: org/slf4j/event/LoggingEvent Logback-classic version 1.1.4 and later require slf4j-api version 1.7.15 or later. With an earlier slf4j-api.jar in the classpath, attempting introspection of a Logger instance returned by logback version 1.1.4 or later will result in a NoClassDefFoundError similar to that shown below. Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/event/LoggingEvent at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2451) at java.lang.Class.privateGetPublicMethods(Class.java:2571) at java.lang.Class.getMethods(Class.java:1429) at java.beans.Introspector.getPublicDeclaredMethods(Introspector.java:1261) at java.beans.Introspector.getTargetMethodInfo(Introspector.java:1122) at java.beans.Introspector.getBeanInfo(Introspector.java:414) at java.beans.Introspector.getBeanInfo(Introspector.java:161) Placing slf4j-api.jar version 1.7.15 or later in the classpath should solve the issue. Note that this problem only occurs with logback version 1.1.4 and later, other bindings such as slf4j-log4j, slf4j-jdk14 and slf4j-simple are unaffected.
09-24
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值