Split member cache

[chachako]

目前在 JHM 结果 https://github.com/meowool-catnip/cloak/runs/5175083247?check_suite_focus=true#step:4:537 中表明 constructor 的缓存要比直接获取要慢，因此可能是不必要的空运算导致的

cloak/api/src/jvmMain/kotlin/com/meowool/cloak/internal/ReflectionFactory.kt

Lines 182 to 205 in 73a1c60

	override fun equals(other: Any?): Boolean {
	if (this === other) return true
	if (other !is MemberCacheKey) return false
	if (kind != other.kind) return false
	if (clasѕ != other.clasѕ) return false
	if (name != other.name) return false
	if (parameters != null) {
	if (other.parameters == null) return false
	if (!parameters.contentEquals(other.parameters)) return false
	} else if (other.parameters != null) return false
	if (returns != other.returns) return false
	return true
	}
	override fun hashCode(): Int {
	var result = kind.hashCode()
	result = 31 * result + clasѕ.hashCode()
	result = 31 * result + (name?.hashCode() ?: 0)
	result = 31 * result + (parameters?.contentHashCode() ?: 0)
	result = 31 * result + (returns?.hashCode() ?: 0)
	return result
	}

考虑将缓存键对象拆分为不同的类 [FieldCacheKey, ConstructorCacheKey, MethodCacheKey]

[chachako]

也需要考虑将 map 分为多个，以避免潜在情况：当反射了非常多不同种类的成员时，map会变得非常大，这可能会影响搜索速度，因此将每个种类的成员分开来也许会更好。

cloak/api/src/main/kotlin/com/meowool/cloak/internal/ReflectionFactory.kt

Lines 43 to 45 in 0b26ee4

	// TODO: Considering that too many caches may bring hash search pressure,
	// we may need to store different kinds of caches in different maps.
	private val membersCache = ConcurrentHashMap<MemberCacheKey, Member>(128)

这个问题解决前需要考虑一个性能阈值，暂时不清楚是否真的需要这么做，1k 的缓存量感觉到头了，hashmap 1k 数据应该不会多慢