前言 最近在 Kotlin 项目中发现，定义的 data class（成员变量都声明不可控）经过在 Gson 解析后，可以得到成员变量为空的对象，而不是得到解析失败，那么就很容易造成后续代码的非预期运行，因为成员变量都按不可空的情况来处理，最终喜提 NullPointerException。 分析原因 在 Gson 的代码中找到实例化对象的地方，经过几种构造方式失败后最终会使用 Unsafe 的来构造实例。 /** * Returns a function that can construct an instance of a requested type. */ public final class ConstructorConstructor { ... public <T> ObjectConstructor<T> get(TypeToken<T> typeToken) { final Type type = typeToken.getType(); final Class<? super T> rawType = typeToken.getRawType(); ... ObjectConstructor<T> defaultConstructor = newDefaultConstructor(rawType); if (defaultConstructor != null) { return defaultConstructor; } ... // finally try unsafe return newUnsafeAllocator(type, rawType); } ... } Unsafe 是位于 sun.misc 包下的一个类，主要提供一些用于执行低级别、不安全操作的方法，如直接访问系统内存资源、自主管理内存资源等，这些方法在提升 Java 运行效率、增强 Java 语言底层资源操作能力方面起到了很大的作用。Unsafe 使 Java 语言拥有了类似 C 语言指针一样操作内存空间的能力，对 Unsafe 的使用一定要慎重。 Gson 采用的便是其对象操作的能力，使用 allocateInstance 方法，达到绕过构造方法创建对象。 try { Class<?> unsafeClass = Class.forName("sun.misc.Unsafe"); Field f = unsafeClass.getDeclaredField("theUnsafe"); f.setAccessible(true); final Object unsafe = f.get(null); final Method allocateInstance = unsafeClass.getMethod("allocateInstance", Class.class); return new UnsafeAllocator() { @Override @SuppressWarnings("unchecked") public <T> T newInstance(Class<T> c) throws Exception { assertInstantiable(c); return (T) allocateInstance.invoke(unsafe, c); } }; } catch (Exception ignored) { } 结论 通过 Unsafe#allocateInstance 实例化的对象绕过了构造函数，在 Koltin 中要额外注意，因为 Kotlin 对非空变量的赋值都会经过 Intrinsics.checkParameterIsNotNull 的处理，而此时构造函数的一系列判断均被绕过，导致上下文不一致。 「「为什么要通过反射来获取 Unsafe？」」 Unsafe 并非单例实现，并且 getUnsafe() 静态方法仅在调用的类为引导类加载器 BootstrapClassLoader 加载时才合法，直接反射获取 Unsafe 实例吧！ public final class Unsafe { private static final Unsafe theUnsafe; ... private Unsafe() { } @CallerSensitive public static Unsafe getUnsafe() { Class var0 = Reflection.getCallerClass(); if(!VM.isSystemDomainLoader(var0.getClassLoader())) { throw new SecurityException("Unsafe"); } else { return theUnsafe; } } ... } Unsafe 的其他应用 在 Android P 版本之后 限制隐藏 API 的调用，作为一个 「「合格」」 开发者应该尊重官方的规则，也有利于项目的长期维护。但偶尔也要试试打破规则！
「「先聊聊系统如何实现这个限制？」」 通常调用隐藏 API 都是通过反射的方式，但是反射的调用也被拦截。 源码分析可以找到 java.lang.Class#getDeclaredMethod() 最终会调用 native 方法 getDeclaredMethodInternal。 static jobject Class_getDeclaredMethodInternal(JNIEnv* env, jobject javaThis, jstring name, jobjectArray args) { ScopedFastNativeObjectAccess soa(env); StackHandleScope<1> hs(soa.Self()); DCHECK_EQ(Runtime::Current()->GetClassLinker()->GetImagePointerSize(), kRuntimePointerSize); DCHECK(!Runtime::Current()->IsActiveTransaction()); Handle<mirror::Method> result = hs.NewHandle( mirror::Class::GetDeclaredMethodInternal<kRuntimePointerSize, false>( soa.Self(), DecodeClass(soa, javaThis), soa.Decode<mirror::String>(name), soa.Decode<mirror::ObjectArray<mirror::Class>>(args))); if (result == nullptr || ShouldBlockAccessToMember(result->GetArtMethod(), soa.Self())) { return nullptr; } return soa.AddLocalReference<jobject>(result.Get()); } 当 「「ShouldBlockAccessToMember」」 返回 true 时，那么直接返回 nullptr，上层就会抛 NoSuchMethodXXX 异常，触发了系统限制。 template<typename T> inline Action GetMemberAction(T* member, Thread* self, std::function<bool(Thread*)> fn_caller_is_trusted, AccessMethod access_method) REQUIRES_SHARED(Locks::mutator_lock_) { DCHECK(member != nullptr); // Decode hidden API access flags. // NB Multiple threads might try to access (and overwrite) these simultaneously, // causing a race. We only do that if access has not been denied, so the race // cannot change Java semantics. We should, however, decode the access flags // once and use it throughout this function, otherwise we may get inconsistent // results, e.g. print whitelist warnings (b/78327881). HiddenApiAccessFlags::ApiList api_list = member->GetHiddenApiAccessFlags(); Action action = GetActionFromAccessFlags(member->GetHiddenApiAccessFlags()); if (action == kAllow) { // Nothing to do. return action; } // Member is hidden. Invoke `fn_caller_in_platform` and find the origin of the access. // This can be *very* expensive. Save it for last. if (fn_caller_is_trusted(self)) { // Caller is trusted. Exit. return kAllow; } // Member is hidden and caller is not in the platform. return detail::GetMemberActionImpl(member, api_list, action, access_method); } 主要判断逻辑中三个条件有一处通过就不会触发系统限制，fn_caller_is_trusted 便是判断调用者的 Class 是否通过 BootClassLoader 加载，所以系统可以直接调用隐藏 API，系统 Class 均由 BootClassLoader 加载。 通过 BootClassLoader 加载的类，其 ClassLoader 则为 null，那么只要将一个业务中已加载 Class 的 ClassLoader 设置为 null ，该 Class 可以通过反射调用隐藏 API 了。 反射是直接修改 Class.classLoader 是行不通的，因为该字段在深灰名单中，会抛 NoSuchFiledException。 「「该 Unsafe 登场了」」 通过 Unsafe 拿到 Class 中 classloader 的偏移量，将偏移量处置为 null。 Class 在内存中的结构如下，前两项变量继承于 Object，分别都是 4 个字节，所以 classloader 的偏移量为 8。 struct Class { Class<?> shadow$_klass_; int shadow$_monitor_; ClassLoader classLoader; } 果然偏移量为 8，输出的是 classloader 信息，设置为 null，再次 getClassLoader 已经变成 BootClassLoader。 class MainActivity : AbsActivity() { override fun onContentLayoutId(): Int = R.layout.activity_main override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) val unsafe = UnsafeAndroid() Timber.d(unsafe.getObject(Reflect::class.java, 8).toString()) unsafe.getAndSetObject(Reflect::class.java, 8, null) Timber.d("${unsafe.getObject(Reflect::class.java, 8)}") Timber.d(Reflect::class.java.classLoader.toString()) } } D/<main><onCreate>(MainActivity.kt:16): dalvik.system.PathClassLoader[DexPathList[[dex file "/data/data/com.x.example/code_cache/.overlay/base.apk/classes2.dex", zip file "/data/app/~~okoSHt8RD79B35SscL93sA==/com.x.example-HuYEILM1Ybt2xxGkn7eViw==/base.apk"],nativeLibraryDirectories=[/data/app/~~okoSHt8RD79B35SscL93sA==/com.x.example-HuYEILM1Ybt2xxGkn7eViw==/lib/arm64, /data/app/~~okoSHt8RD79B35SscL93sA==/com.x.example-HuYEILM1Ybt2xxGkn7eViw==/base.apk!/lib/arm64-v8a, /system/lib64, /system_ext/lib64]]] D/<main><onCreate>(MainActivity.kt:18): null D/<main><onCreate>(MainActivity.kt:19): java.lang.BootClassLoader@42a2eb