JNI Debug 3 (thread debug env variable problem)

JNI Layer Debug Thread crash reason

One, causing the crash reason:

In the thread function of the JNI layer, as long as the function called Env is added, it freezes two, the solution first we should understand: ① (Independence) jnienv is a thread-related variable, that is, thread A has a jnienv variable, thread B also has a jnienv variable, because thread-related, so a A thread cannot use the jnienv struct variable of a B thread. So how do you ensure the independence of each thread jnienv?

A Java object sends a message to the server via the JNI call DLL in a Send () function, returns immediately without waiting for the server message, and jnienv the JNI interface pointer to *env (virtual machine environment pointer), and Jobject obj is stored in a variable in a DLL. After a period of time, the message receiving thread in the DLL receives a message from the server and attempts to process the message by using the saved Env and Obj methods (equivalent to the Java callback method) to invoke the previous Java object, and the program suddenly exits (crashes ).

That is, the foreground Java thread sends a message, the background thread processes the message, belongs to two different threads, cannot use the same jnienv variable, and there is a mechanism to take advantage of the global JAVAVM * pointer to get the jnienv* pointer of the current thread , as in C + + The same principle that two threads use TLS for local storage.

Specific methods:

Get the global JAVAVM variable:

/* Our VMS */
JAVAVM *G_VM;

ENV->GETJAVAVM (&G_VM); To get the JAVAVM pointer. Once this pointer is obtained, the JAVAVM is saved. Transcription

② (Public Sex) first understand TLS(Thread-local storage)

A thread is a unit of execution, and multiple threads within the same process share the address space of the process, and the thread generally has its own stack, but if you want to implement a global variable that takes a different value between different threads and is unaffected. One way is to use the thread synchronization mechanism, such as the reading and writing of this variable in the critical area or mutex, but this is at the expense of efficiency, can not lock it? Thread-local storage is doing this.

Solve the above two questions: 1 define global variables first

namespace android{       static javavm* GJAVAVM  = NULL;  // defining a global Java VM Reference object       Static // defines a global Java object, for the Java Layer class object
......
       

2 is defined next in the function that invokes a thread: (to ensure the common nature of the thread's resources in the process, which is to pass parameters to the threads)

void Jnicall Java_test_setenev (jnienv *env, Jobject obj)  {      env// Save to global variable JVM         the direct assignment of obj to a global variable in a DLL is not possible, and the following   function should be called:    gs_object=env->newglobalref (obj);     HANDLE HT=createthread (NULL,0, (lpthread_start_routine) Threadfun,0, null,null);  } 

3 references in thread functions: (Ensure that the threading function corresponds to Env and class)

voidWINAPI Threadfun (PVOID argv)//JNI Thread Callback this method{jnienv*env; GS_JVM->attachcurrentthread ((void* *) &env, NULL); The corresponding sentence is simply to remove the variable from the above function to use the Jclass CLS in that thread= Env->getobjectclass (Gs_object);//getting global objects in a Java threadJfieldid fieldptr= Env->getfieldid (CLS,"value","I");//get Java Object    while(1) {Sleep ( -); //This changes the property value of the Java object (callback Java)Env->setintfield (Gs_object,fieldptr, (jint) gs_i++); }  }

Third, we saw some information about the JNI program on the Internet (*env)->;

We need to keep in mind: Under Linux, if you compile with "env->" in. c files, you cannot find this structure, you must use "(*env)," or change to a. cpp file to compile in C + +.

------------------------------------------------------------------------

JNI Debug 3 (thread debug env variable problem)