Home » Android » java – What are the consequences if we try to attach a Native Thread permanently to the DVM (JVM)?

java – What are the consequences if we try to attach a Native Thread permanently to the DVM (JVM)?

Posted by: admin May 14, 2020 Leave a comment


Is it feasible to attach a native thread permanently to the JVM (AttachCurrentThread) (or) is it better to attach when ever required (calling java functions) and detach immediately once the work is done

I wrote a sample native app with the above cases, didn’t find any difference. But by googling, vaguely I came to know that, when attached to JVM , JVMs thread scheduling is responsible for scheduling else OS will schedule the native thread (if not attached). Is this true?

It is important to detach any thread that has been previously attached; otherwise, the program will not exit when you call DestroyJavaVM. – http://java.sun.com/developer/onlineTraining/Programming/JDCBook/jniref.html#attach

Will there by any performance issues?
Please let me know if anyone knows, its one my important design aspect.

Thanks & Regards.

How to&Answers:

Generally speaking, the main performance cost is the thread creation at OS level. Either the thread is creating natively and then attached or directly created as java.lang.Thread from Java API.

If you re-use the same native thread, performance will be good. By the way, do not create dozens of native threads.

The JVM does not schedule threads itself. It may force them in sleep state for various reason like garbage collection. In that specific case, it has to wait for a JNI call from a native thread before collecting. So you have to avoid too long code execution without JNI call to keep the VM heap consumption low.

Moreover, you have to take care to call DeleteLocalRef before detaching a native thread or else your VM will leak memory.


When a native thread is attached permanently, not able to exit the native thread. Its crashing when we try exiting the native thread without detaching. But when we detached, native thread was able to do graceful exit.


I haven’t experienced any consequences except for boosted performance.

That is exactly what I do in an application that is shuffling directly-allocated ByteBuffer data between the two layers. I discovered the cost of constantly attaching/detaching was very high, as one might expect. My approach is to launch a single Java-managed thread that makes a blocking JNI call at launch, which in the C/C++ layer contains a condition/signal-style loop (so as to not eat CPU cycles). I can then signal down to the loop anytime data is ready for processing, and conversely I can signal up to Java when the hard work is done.

new Thread(() -> myBlockingJNICall()).start();

Then down in the C layer:

#ifdef __cplusplus
extern "C"
#endif // __cplusplus

    static JavaVM *jvm = nullptr; // captures the JVM on load

    JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM *the_jvm, void* /*reserved*/)
        jvm = the_jvm;
        return JNI_VERSION_1_2; // must export 1_2 to use any of the new functions, 1_1 otherwise

    JNIEXPORT jboolean JNICALL Java_myBlockingJNICall(JNIEnv *env, jobject)
       // loop forever waiting for work and using env for signalling
       // jvm is stored in case we need to manually attach (or perform more complex work requiring jvm access)
       return JNI_TRUE;

#ifdef __cplusplus
#endif // __cplusplus