前言
最近在 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() {
("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() {
}
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 的调用
https://developer.android.com/guide/app-compatibility/restrictions-non-sdk-interfaces?hl=zh-cn。
「「先聊聊系统如何实现这个限制？」」
通常调用隐藏 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
