Xamarin.Android Java.Interop Concurrency Latency

Direct answer

No. Exposing a public per-thread JNIEnv cache would not eliminate the contention you are seeing, because JNIEnv is already thread-local by specification and Java.Interop already caches per-thread environment state. A lock-free interop API is also not a practical general fix: JNI global references, handle tables, and the Java/managed GC bridge still require coordination and safe-point guarantees. At eight or more threads, the lower-latency path is usually structural—reduce the number of JNI transitions, batch work, or confine calls to one owning thread—not a new public API surface.

Confirmed facts vs likely explanation

Confirmed by the JNI specification and Java.Interop design: each attached thread obtains its own JNIEnv via JavaVM::GetEnv or AttachCurrentThread. A single shared JNIEnv pointer is not the usual contention point. Java.Interop already maintains thread-local environment info and the environment pointer, so a public per-thread cache would largely formalize existing internal behavior rather than remove a global monitor.

Likely explanation for the latency rise: shared runtime bookkeeping around JNI reference and handle tables, thread attach/registration locks, and GC-bridge or GC safe-point transitions between the managed collector and ART's collector. A fully lock-free interop API is not straightforwardly achievable because those structures need coordination and reference-lifetime guarantees.

Unverified in this context: the specific 0.2–0.5 ms at 1–2 threads and 2–5 ms at 8+ threads, and the claim that this is documented across Xamarin.Android 12.2–13.0. Treat those as a hypothesis to reproduce, not established fact. Xamarin.Android has been superseded by .NET for Android, and newer releases changed JNI dispatch and GC bridging, so behavior measured on 12.x/13.x may not carry over.

What to measure before changing any API

Mean latency hides tail behavior. Record p50, p95, and p99 per call at 1, 2, 4, 8, and 16 threads on a physical device, not an emulator. A minimal harness pattern:

var samples = new ConcurrentBag<double>();
// per thread: loop N times, Stopwatch.StartNew() around the Java call
// after the run: sort samples, report p50/p95/p99

Profile lock contention and GC transitions with managed tooling (dotnet-trace or PerfView) alongside native/ART tooling (Perfetto, systrace, or simpleperf). Then A/B test the same workload with:

• a single dedicated interop thread,
• per-thread objects instead of one shared object,
• the hot path moved into Java or native code.

If the single-thread version is dramatically faster, the bottleneck is transition count or shared bookkeeping, not a missing JNIEnv cache. If the Java method itself is synchronized or touches shared native state, fix that first; interop API changes will not help.

One diagnostic detail that changes the recommendation

Is the Java method synchronized, or does it acquire a shared native lock? If yes, the contention is in the Java/native layer, and the right fix is to remove that lock or shard the work—not to add a per-thread JNIEnv cache or a lock-free interop API. If the method is unsynchronized and the profile still shows JNI-layer blocking, then structural batching or a dedicated interop thread is the next step.

Version and review note

This answer assumes Xamarin.Android 12.x–13.x behavior as described in the question. Because those releases are end-of-support and .NET for Android has different interop internals, verify on your actual toolchain before committing to an architecture change. The latency figures and the “documented across releases” claim require current verification.