常用字符与ASCII代码对照表字符,代码,常用字符,字符字符,ASCII,对照表,代码对照表
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
常用字符与ASCII代码对照表
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口您所在的位置： &
sinh和asinh--双曲正弦和反双曲正弦函数
sinh和asinh--双曲正弦和反双曲正弦函数
电子工业出版社
《脑动力：MATLAB函数功能速查效率手册》第5章数学函数，本章将从基本数学函数和数据分析函数两方面进行介绍。本节为大家介绍sinh和asinh--双曲正弦和反双曲正弦函数。
5.1.2& sinh和asinh--双曲正弦和反双曲正弦函数
【功能简介】求变量的双曲正弦和反双曲正弦。
【语法格式】
1．Y=sinh(X)
求X中元素的双曲正弦。自变量x的双曲正弦等于(ex-e-x)/2。
2．Y=asinh(X)
求元素的反双曲正弦。自变量x的反双曲正弦等于log[x+(x2+1)1/2]。
【实例5.2】求双曲正弦与反双曲正弦。&x=-4:.1:4; &&y=sinh(x);&&&&&&&&&&&&&&&&&&&%求双曲正弦 &&plot(x,y);grid&&&&&&&&&&&&%绘制双曲正弦曲线 &&y=asinh(x);&&&&&&&&&&&&&&%求反双曲正弦 &&plot(x,y);grid&&&&&%绘制反双曲正弦曲线 &
执行结果如图5-3和图5-4所示。
图5-3& 双曲正弦曲线
图5-4& 反双曲正弦曲线【实例分析】双曲正弦与反双曲正弦是一对反函数。【责任编辑： TEL：（010）】&&&&&&
关于&&的更多文章
这本书是写给程序员和项目经理的。作者结合自身的丰富成长历程，
本书描述了黑客用默默无闻的行动为数字世界照亮了一条道路的故事。
享誉全球的未来学家理查德.沃森，用科学和多元的视角
本书是图文并茂的Python学习参考书，书中并不包含深奥
对于任何一门编程语言来说，算法都是程序的"灵魂"。正
本书是AJAX之父的经典之作。本书用简洁的语言系统化地诠释了设计、技术和商业融合是最重要的发展趋势。全书共8章，包括关于用户
51CTO旗下网站7183人阅读
android端JNI的打印信息:
#include &android/log.h&
#ifndef &LOG_TAG
#define &LOG_TAG & &&h264AndroidJNI&
#define &LOGI(...) &__android_log_print(ANDROID_LOG_INFO,LOG_TAG,__VA_ARGS__)
#define &LOGE(...) &__android_log_print(ANDROID_LOG_ERROR,LOG_TAG,__VA_ARGS__)
* Copyright (C) 2007 The Android Open Source Project
* Licensed under the Apache License, Version 2.0 (the &License&);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an &AS IS& BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
#include &time.h&
#include &stdio.h&
#ifdef HAVE_PTHREADS
#include &pthread.h&
#include &unistd.h&
#include &errno.h&
#include &fcntl.h&
#include &string.h&
#include &stdlib.h&
#include &stdarg.h&
#include &utils/logger.h&
#include &cutils/logd.h&
#define LOG_BUF_SIZE 1024
#if FAKE_LOG_DEVICE
// This will be defined when building for the host.
#define log_open(pathname, flags) fakeLogOpen(pathname, flags)
#define log_writev(filedes, vector, count) fakeLogWritev(filedes, vector, count)
#define log_close(filedes) fakeLogClose(filedes)
#define log_open(pathname, flags) open(pathname, flags)
#define log_writev(filedes, vector, count) writev(filedes, vector, count)
#define log_close(filedes) close(filedes)
typedef enum {
LOG_ID_MAIN = 0,
LOG_ID_RADIO,
LOG_ID_EVENTS,
LOG_ID_MAX
} log_id_t;
static int __write_to_log_init(log_id_t, struct iovec *vec, size_t nr);
static int (*write_to_log)(log_id_t, struct iovec *vec, size_t nr) =
__write_to_log_
#ifdef HAVE_PTHREADS
static pthread_mutex_t log_init_lock = PTHREAD_MUTEX_INITIALIZER;
static int log_fds[(int)LOG_ID_MAX] = { -1, -1, -1 };
* This is used by the C++ code to decide if it should write logs through
* the C code.
Basically, if /dev/log/... is available, we're running in
* the simulator rather than a desktop tool and want to use the device.
static enum {
kLogUninitialized, kLogNotAvailable, kLogAvailable
} g_log_status = kLogU
int __android_log_dev_available(void)
if (g_log_status == kLogUninitialized) {
if (access(&/dev/&LOGGER_LOG_MAIN, W_OK) == 0)
g_log_status = kLogA
g_log_status = kLogNotA
return (g_log_status == kLogAvailable);
static int __write_to_log_null(log_id_t log_fd, struct iovec *vec, size_t nr)
return -1;
static int __write_to_log_kernel(log_id_t log_id, struct iovec *vec, size_t nr)
if (/*(int)log_id &= 0 &&*/ (int)log_id & (int)LOG_ID_MAX) {
log_fd = log_fds[(int)log_id];
return EBADF;
ret = log_writev(log_fd, vec, nr);
} while (ret & 0 && errno == EINTR);
static int __write_to_log_init(log_id_t log_id, struct iovec *vec, size_t nr)
#ifdef HAVE_PTHREADS
pthread_mutex_lock(&log_init_lock);
if (write_to_log == __write_to_log_init) {
log_fds[LOG_ID_MAIN] = log_open(&/dev/&LOGGER_LOG_MAIN, O_WRONLY);
log_fds[LOG_ID_RADIO] = log_open(&/dev/&LOGGER_LOG_RADIO, O_WRONLY);
log_fds[LOG_ID_EVENTS] = log_open(&/dev/&LOGGER_LOG_EVENTS, O_WRONLY);
write_to_log = __write_to_log_
if (log_fds[LOG_ID_MAIN] & 0 || log_fds[LOG_ID_RADIO] & 0 ||
log_fds[LOG_ID_EVENTS] & 0) {
log_close(log_fds[LOG_ID_MAIN]);
log_close(log_fds[LOG_ID_RADIO]);
log_close(log_fds[LOG_ID_EVENTS]);
log_fds[LOG_ID_MAIN] = -1;
log_fds[LOG_ID_RADIO] = -1;
log_fds[LOG_ID_EVENTS] = -1;
write_to_log = __write_to_log_
#ifdef HAVE_PTHREADS
pthread_mutex_unlock(&log_init_lock);
return write_to_log(log_id, vec, nr);
int __android_log_write(int prio, const char *tag, const char *msg)
struct iovec vec[3];
log_id_t log_id = LOG_ID_MAIN;
/* XXX: This needs to go! */
if (!strcmp(tag, &HTC_RIL&) ||
!strcmp(tag, &RILJ&) ||
!strcmp(tag, &RILC&) ||
!strcmp(tag, &RIL&) ||
!strcmp(tag, &AT&) ||
!strcmp(tag, &GSM&) ||
!strcmp(tag, &STK&))
log_id = LOG_ID_RADIO;
vec[0].iov_base
= (unsigned char *) &
vec[0].iov_len
vec[1].iov_base
= (void *)
vec[1].iov_len
= strlen(tag) + 1;
vec[2].iov_base
= (void *)
vec[2].iov_len
= strlen(msg) + 1;
return write_to_log(log_id, vec, 3);
int __android_log_vprint(int prio, const char *tag, const char *fmt, va_list ap)
char buf[LOG_BUF_SIZE];
vsnprintf(buf, LOG_BUF_SIZE, fmt, ap);
return __android_log_write(prio, tag, buf);
int __android_log_print(int prio, const char *tag, const char *fmt, ...)
char buf[LOG_BUF_SIZE];
va_start(ap, fmt);
vsnprintf(buf, LOG_BUF_SIZE, fmt, ap);
va_end(ap);
return __android_log_write(prio, tag, buf);
void __android_log_assert(const char *cond, const char *tag,
const char *fmt, ...)
char buf[LOG_BUF_SIZE];
va_start(ap, fmt);
vsnprintf(buf, LOG_BUF_SIZE, fmt, ap);
va_end(ap);
__android_log_write(ANDROID_LOG_FATAL, tag, buf);
__builtin_trap(); /* trap so we have a chance to debug the situation */
int __android_log_bwrite(int32_t tag, const void *payload, size_t len)
struct iovec vec[2];
vec[0].iov_base = &
vec[0].iov_len = sizeof(tag);
vec[1].iov_base = (void*)
vec[1].iov_len =
return write_to_log(LOG_ID_EVENTS, vec, 2);
* Like __android_log_bwrite, but takes the type as well.
Doesn't work
* for the general case where we're generating lists of stuff, but very
* handy if we just want to dump an integer into the log.
int __android_log_btwrite(int32_t tag, char type, const void *payload,
size_t len)
struct iovec vec[3];
vec[0].iov_base = &
vec[0].iov_len = sizeof(tag);
vec[1].iov_base = &
vec[1].iov_len = sizeof(type);
vec[2].iov_base = (void*)
vec[2].iov_len =
return write_to_log(LOG_ID_EVENTS, vec, 3);
syntax highlighted by Code2HTML, v. 0.9.1
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：319912次
积分：4704
积分：4704
排名：第2646名
原创：102篇
转载：307篇
评论：36条
(1)(1)(2)(12)(3)(1)(2)(3)(20)(18)(11)(4)(8)(6)(17)(12)(17)(11)(11)(6)(15)(16)(16)(4)(6)(1)(17)(11)(9)(9)(14)(11)(20)(18)(67)(9)关于反射调用方法的一个log - Script Ahead, Code Behind - ITeye技术网站
博客分类：
刚才在JavaEye问答频道看到了：
liu0013 写道[Loaded sun.reflect.GeneratedMethodAccessor197 from __JVM_DefineClass__]
请问报这个是什么意思？
这是Sun实现的Java标准库的一个细节。下面举例稍微讲解一下。
假如有这么一个类A：
public class A {
public void foo(String name) {
System.out.println("Hello, " + name);
}
可以编写另外一个类来反射调用A上的方法：
import java.lang.reflect.M
public class TestClassLoad {
public static void main(String[] args) throws Exception {
Class&?& clz = Class.forName("A");
Object o = clz.newInstance();
Method m = clz.getMethod("foo", String.class);
for (int i = 0; i & 16; i++) {
m.invoke(o, Integer.toString(i));
}
注意到TestClassLoad类上不会有对类A的符号依赖——也就是说在加载并初始化TestClassLoad类时不需要关心类A的存在与否，而是等到main()方法执行到调用Class.forName()时才试图对类A做动态加载；这里用的是一个参数版的forName()，也就是使用当前方法所在类的ClassLoader来加载，并且初始化新加载的类。……好吧这个细节跟主题没啥关系。
回到主题。这次我的测试环境是Sun的JDK 1.6.0 update 13 build 03。编译上述代码，并在执行TestClassLoad时加入-XX:+TraceClassLoading参数（或者-verbose:class或者直接-verbose都行），如下：
java -XX:+TraceClassLoading TestClassLoad
可以看到输出了一大堆log，把其中相关的部分截取出来如下：（完整的log可以从附件下载）
[Loaded TestClassLoad from file:/D:/temp_code/test_java_classload/]
[Loaded A from file:/D:/temp_code/test_java_classload/]
[Loaded sun.reflect.NativeMethodAccessorImpl from shared objects file]
[Loaded sun.reflect.DelegatingMethodAccessorImpl from shared objects file]
[Loaded sun.reflect.ClassFileConstants from shared objects file]
[Loaded sun.reflect.AccessorGenerator from shared objects file]
[Loaded sun.reflect.MethodAccessorGenerator from shared objects file]
[Loaded sun.reflect.ByteVectorFactory from shared objects file]
[Loaded sun.reflect.ByteVector from shared objects file]
[Loaded sun.reflect.ByteVectorImpl from shared objects file]
[Loaded sun.reflect.ClassFileAssembler from shared objects file]
[Loaded sun.reflect.UTF8 from shared objects file]
[Loaded java.lang.Void from shared objects file]
[Loaded sun.reflect.Label from shared objects file]
[Loaded sun.reflect.Label$PatchInfo from shared objects file]
[Loaded java.util.AbstractList$Itr from shared objects file]
[Loaded sun.reflect.MethodAccessorGenerator$1 from shared objects file]
[Loaded sun.reflect.ClassDefiner from shared objects file]
[Loaded sun.reflect.ClassDefiner$1 from shared objects file]
[Loaded sun.reflect.GeneratedMethodAccessor1 from __JVM_DefineClass__]
Hello, 15
可以看到前15次反射调用A.foo()方法并没有什么稀奇的地方，但在第16次反射调用时似乎有什么东西被触发了，导致JVM新加载了一堆类，其中就包括[Loaded sun.reflect.GeneratedMethodAccessor1 from __JVM_DefineClass__]这么一行。这是哪里来的呢？
先来看看JDK里Method.invoke()是怎么实现的。
java.lang.reflect.Method：
public final
class Method extends AccessibleObject implements GenericDeclaration,
private volatile MethodAccessor methodA
// For sharing of MethodAccessors. This branching structure is
// currently only two levels deep (i.e., one root Method and
// potentially many Method objects pointing to it.)
private Meth
public Object invoke(Object obj, Object... args)
throws IllegalAccessException, IllegalArgumentException,
InvocationTargetException
if (!override) {
if (!Reflection.quickCheckMemberAccess(clazz, modifiers)) {
Class caller = Reflection.getCallerClass(1);
Class targetClass = ((obj == null || !Modifier.isProtected(modifiers))
: obj.getClass());
synchronized (this) {
cached = (securityCheckCache == caller)
&& (securityCheckTargetClassCache == targetClass);
if (!cached) {
Reflection.ensureMemberAccess(caller, clazz, obj, modifiers);
synchronized (this) {
securityCheckCache =
securityCheckTargetClassCache = targetC
if (methodAccessor == null) acquireMethodAccessor();
return methodAccessor.invoke(obj, args);
// NOTE that there is no synchronization used here. It is correct
// (though not efficient) to generate more than one MethodAccessor
// for a given Method. However, avoiding synchronization will
// probably make the implementation more scalable.
private void acquireMethodAccessor() {
// First check to see if one has been created yet, and take it
MethodAccessor tmp =
if (root != null) tmp = root.getMethodAccessor();
if (tmp != null) {
methodAccessor =
// Otherwise fabricate one and propagate it up to the root
tmp = reflectionFactory.newMethodAccessor(this);
setMethodAccessor(tmp);
}
可以看到Method.invoke()实际上并不是自己实现的反射调用逻辑，而是委托给sun.reflect.MethodAccessor来处理。
每个实际的Java方法只有一个对应的Method对象作为root，。这个root是不会暴露给用户的，而是每次在通过反射获取Method对象时新创建Method对象把root包装起来再给用户。在第一次调用一个实际Java方法对应得Method对象的invoke()方法之前，实现调用逻辑的MethodAccessor对象还没创建；等第一次调用时才新创建MethodAccessor并更新给root，然后调用MethodAccessor.invoke()真正完成反射调用。
那么MethodAccessor是啥呢？
sun.reflect.MethodAccessor：
public interface MethodAccessor {
/** Matches specification in {@link java.lang.reflect.Method} */
public Object invoke(Object obj, Object[] args)
throws IllegalArgumentException, InvocationTargetE
}
可以看到它只是一个单方法接口，其invoke()方法与Method.invoke()的对应。
创建MethodAccessor实例的是ReflectionFactory。
sun.reflect.ReflectionFactory：
public class ReflectionFactory {
private static boolean initted =
// "Inflation" mechanism. Loading bytecodes to implement
// Method.invoke() and Constructor.newInstance() currently costs
// 3-4x more than an invocation via native code for the first
// invocation (though subsequent invocations have been benchmarked
// to be over 20x faster). Unfortunately this cost increases
// startup time for certain applications that use reflection
// intensively (but only once per class) to bootstrap themselves.
// To avoid this penalty we reuse the existing JVM entry points
// for the first few invocations of Methods and Constructors and
// then switch to the bytecode-based implementations.
// Package-private to be accessible to NativeMethodAccessorImpl
// and NativeConstructorAccessorImpl
private static boolean noInflation
private static int
inflationThreshold = 15;
/** We have to defer full initialization of this class until after
the static initializer is run since java.lang.reflect.Method's
static initializer (more properly, that for
java.lang.reflect.AccessibleObject) causes this class's to be
run, before the system properties are set up. */
private static void checkInitted() {
if (initted)
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
// Tests to ensure the system properties table is fully
// initialized. This is needed because reflection code is
// called very early in the initialization process (before
// command-line arguments have been parsed and therefore
// these user-settable properties installed.) We assume that
// if System.out is non-null then the System class has been
// fully initialized and that the bulk of the startup code
// has been run.
if (System.out == null) {
// java.lang.System not yet fully initialized
String val = System.getProperty("sun.reflect.noInflation");
if (val != null && val.equals("true")) {
noInflation =
val = System.getProperty("sun.reflect.inflationThreshold");
if (val != null) {
inflationThreshold = Integer.parseInt(val);
} catch (NumberFormatException e) {
throw (RuntimeException)
new RuntimeException("Unable to parse property sun.reflect.inflationThreshold").
initCause(e);
public MethodAccessor newMethodAccessor(Method method) {
checkInitted();
if (noInflation) {
return new MethodAccessorGenerator().
generateMethod(method.getDeclaringClass(),
method.getName(),
method.getParameterTypes(),
method.getReturnType(),
method.getExceptionTypes(),
method.getModifiers());
NativeMethodAccessorImpl acc =
new NativeMethodAccessorImpl(method);
DelegatingMethodAccessorImpl res =
new DelegatingMethodAccessorImpl(acc);
acc.setParent(res);
}
这里就可以看到有趣的地方了。如注释所述，实际的MethodAccessor实现有两个版本，一个是Java实现的，另一个是native code实现的。Java实现的版本在初始化时需要较多时间，但长久来说性能较好；native版本正好相反，启动时相对较快，但运行时间长了之后速度就比不过Java版了。这是HotSpot的优化方式带来的性能特性，同时也是许多虚拟机的共同点：跨越native边界会对优化有阻碍作用，它就像个黑箱一样让虚拟机难以分析也将其内联，于是运行时间长了之后反而是托管版本的代码更快些。
为了权衡两个版本的性能，Sun的JDK使用了“inflation”的技巧：让Java方法在被反射调用时，开头若干次使用native版，等反射调用次数超过阈值时则生成一个专用的MethodAccessor实现类，生成其中的invoke()方法的字节码，以后对该Java方法的反射调用就会使用Java版。
Sun的JDK是从1.4系开始采用这种优化的，主要作者是
上面看到了ReflectionFactory.newMethodAccessor()生产MethodAccessor的逻辑，在“开头若干次”时用到的DelegatingMethodAccessorImpl代码如下：
sun.reflect.DelegatingMethodAccessorImpl：
/** Delegates its invocation to another MethodAccessorImpl and can
change its delegate at run time. */
class DelegatingMethodAccessorImpl extends MethodAccessorImpl {
private MethodAccessorI
DelegatingMethodAccessorImpl(MethodAccessorImpl delegate) {
setDelegate(delegate);
public Object invoke(Object obj, Object[] args)
throws IllegalArgumentException, InvocationTargetException
return delegate.invoke(obj, args);
void setDelegate(MethodAccessorImpl delegate) {
this.delegate =
}
这是一个间接层，方便在native与Java版的MethodAccessor之间实现切换。
然后下面就是native版MethodAccessor的Java一侧的声明：
sun.reflect.NativeMethodAccessorImpl：
/** Used only for the first few invocations of a M afterward,
switches to bytecode-based implementation */
class NativeMethodAccessorImpl extends MethodAccessorImpl {
private DelegatingMethodAccessorI
private int numI
NativeMethodAccessorImpl(Method method) {
this.method =
public Object invoke(Object obj, Object[] args)
throws IllegalArgumentException, InvocationTargetException
if (++numInvocations & ReflectionFactory.inflationThreshold()) {
MethodAccessorImpl acc = (MethodAccessorImpl)
new MethodAccessorGenerator().
generateMethod(method.getDeclaringClass(),
method.getName(),
method.getParameterTypes(),
method.getReturnType(),
method.getExceptionTypes(),
method.getModifiers());
parent.setDelegate(acc);
return invoke0(method, obj, args);
void setParent(DelegatingMethodAccessorImpl parent) {
this.parent =
private static native Object invoke0(Method m, Object obj, Object[] args);
}
每次NativeMethodAccessorImpl.invoke()方法被调用时，都会增加一个调用次数计数器，看超过阈值没有；一旦超过，则调用MethodAccessorGenerator.generateMethod()来生成Java版的MethodAccessor的实现类，并且改变DelegatingMethodAccessorImpl所引用的MethodAccessor为Java版。后续经由DelegatingMethodAccessorImpl.invoke()调用到的就是Java版的实现了。
注意到关键的invoke0()方法是个native方法。它在HotSpot VM里是由JVM_InvokeMethod()函数所支持的：
JNIEXPORT jobject JNICALL Java_sun_reflect_NativeMethodAccessorImpl_invoke0
(JNIEnv *env, jclass unused, jobject m, jobject obj, jobjectArray args)
return JVM_InvokeMethod(env, m, obj, args);
}
JVM_ENTRY(jobject, JVM_InvokeMethod(JNIEnv *env, jobject method, jobject obj, jobjectArray args0))
JVMWrapper("JVM_InvokeMethod");
Handle method_
if (thread-&stack_available((address) &method_handle) &= JVMInvokeMethodSlack) {
method_handle = Handle(THREAD, JNIHandles::resolve(method));
Handle receiver(THREAD, JNIHandles::resolve(obj));
objArrayHandle args(THREAD, objArrayOop(JNIHandles::resolve(args0)));
oop result = Reflection::invoke_method(method_handle(), receiver, args, CHECK_NULL);
jobject res = JNIHandles::make_local(env, result);
if (JvmtiExport::should_post_vm_object_alloc()) {
oop ret_type = java_lang_reflect_Method::return_type(method_handle());
assert(ret_type != NULL, "sanity check: ret_type oop must not be NULL!");
if (java_lang_Class::is_primitive(ret_type)) {
// Only for primitive type vm allocates memory for java object.
// See box() method.
JvmtiExport::post_vm_object_alloc(JavaThread::current(), result);
THROW_0(vmSymbols::java_lang_StackOverflowError());
JVM_END
其中的关键又是Reflection::invoke_method()：
// This would be nicer if, say, java.lang.reflect.Method was a subclass
// of java.lang.reflect.Constructor
oop Reflection::invoke_method(oop method_mirror, Handle receiver, objArrayHandle args, TRAPS) {
oop mirror
= java_lang_reflect_Method::clazz(method_mirror);
= java_lang_reflect_Method::slot(method_mirror);
bool override
= java_lang_reflect_Method::override(method_mirror) != 0;
objArrayHandle ptypes(THREAD, objArrayOop(java_lang_reflect_Method::parameter_types(method_mirror)));
oop return_type_mirror = java_lang_reflect_Method::return_type(method_mirror);
if (java_lang_Class::is_primitive(return_type_mirror)) {
rtype = basic_type_mirror_to_basic_type(return_type_mirror, CHECK_NULL);
rtype = T_OBJECT;
instanceKlassHandle klass(THREAD, java_lang_Class::as_klassOop(mirror));
methodOop m = klass-&method_with_idnum(slot);
if (m == NULL) {
THROW_MSG_0(vmSymbols::java_lang_InternalError(), "invoke");
methodHandle method(THREAD, m);
return invoke(klass, method, receiver, override, ptypes, rtype, args, true, THREAD);
}
再下去就深入到HotSpot VM的内部了，本文就在这里打住吧。有同学有兴趣深究的话以后可以再写一篇讨论native版的实现。
回到Java的一侧。MethodAccessorGenerator长啥样呢？由于代码太长，这里就不完整贴了，有兴趣的可以到OpenJDK 6的Mercurial仓库看：。它的基本工作就是在内存里生成新的专用Java类，并将其加载。就贴这么一个方法：
private static synchronized String generateName(boolean isConstructor,
boolean forSerialization)
if (isConstructor) {
if (forSerialization) {
int num = ++serializationConstructorS
return "sun/reflect/GeneratedSerializationConstructorAccessor" +
int num = ++constructorS
return "sun/reflect/GeneratedConstructorAccessor" +
int num = ++methodS
return "sun/reflect/GeneratedMethodAccessor" +
}
去阅读源码的话，可以看到MethodAccessorGenerator是如何一点点把Java版的MethodAccessor实现类生产出来的。也可以看到GeneratedMethodAccessor+数字这种名字是从哪里来的了，就在上面的generateName()方法里。
对本文开头的例子的A.foo()，生成的Java版MethodAccessor大致如下：
package sun.
public class GeneratedMethodAccessor1 extends MethodAccessorImpl {
public GeneratedMethodAccessor1() {
public Object invoke(Object obj, Object[] args)
throws IllegalArgumentException, InvocationTargetException {
// prepare the target and parameters
if (obj == null) throw new NullPointerException();
A target = (A)
if (args.length != 1) throw new IllegalArgumentException();
String arg0 = (String) args[0];
} catch (ClassCastException e) {
throw new IllegalArgumentException(e.toString());
} catch (NullPointerException e) {
throw new IllegalArgumentException(e.toString());
// make the invocation
target.foo(arg0);
} catch (Throwable t) {
throw new InvocationTargetException(t);
}
就反射调用而言，这个invoke()方法非常干净（然而就“正常调用”而言这额外开销还是明显的）。注意到参数数组被拆开了，把每个参数都恢复到原本没有被Object[]包装前的样子，然后对目标方法做正常的invokevirtual调用。由于在生成代码时已经循环遍历过参数类型的数组，生成出来的代码里就不再包含循环了。
当该反射调用成为热点时，它甚至可以被内联到靠近Method.invoke()的一侧，大大降低了反射调用的开销。而native版的反射调用则无法被有效内联，因而调用开销无法随程序的运行而降低。
虽说Sun的JDK这种实现方式使得反射调用方法成本比以前降低了很多，但Method.invoke()本身要用数组包装参数；而且每次调用都必须检查方法的可见性（在Method.invoke()里），也必须检查每个实际参数与形式参数的类型匹配性（在NativeMethodAccessorImpl.invoke0()里或者生成的Java版MethodAccessor.invoke()里）；而且Method.invoke()就像是个独木桥一样，各处的反射调用都要挤过去，在调用点上收集到的类型信息就会很乱，影响内联程序的判断，使得Method.invoke()自身难以被内联到调用方。
相比之下则更有潜力，在其功能完全实现后能达到比普通反射调用方法更高的性能。在使用MethodHandle来做反射调用时，MethodHandle.invoke()的形式参数与返回值类型都是准确的，所以只需要在链接方法的时候才需要检查类型的匹配性，而不必在每次调用时都检查。而且MethodHandle是不可变值，在创建后其内部状态就不会再改变了；JVM可以利用这个知识而放心的对它做激进优化，例如将实际的调用目标内联到做反射调用的一侧。
到本来Java的安全机制使得不同类之间不是任意信息都可见，但Sun的JDK里开了个口，有一个标记类专门用于开后门：
package sun.
/** &P& MagicAccessorImpl (named for parity with FieldAccessorImpl and
others, not because it actually implements an interface) is a
marker class in the hierarchy. All subclasses of this class are
"magically" granted access by the VM to otherwise inaccessible
fields and methods of other classes. It is used to hold the code
for dynamically-generated FieldAccessorImpl and MethodAccessorImpl
subclasses. (Use of the word "unsafe" was avoided in this class's
name to avoid confusion with {@link sun.misc.Unsafe}.) &/P&
&P& The bug fix for 4486457 also necessitated disabling
verification for this class and all subclasses, as opposed to just
SerializationConstructorAccessorImpl and subclasses, to avoid
having to indicate to the VM which of these dynamically-generated
stub classes were known to be able to pass the verifier. &/P&
&P& Do not change the name of this class without also changing the
VM's code. &/P& */
class MagicAccessorImpl {
那个"__JVM_DefineClass__"的来源是这里：
src/share/vm/prims/jvm.cpp
// common code for JVM_DefineClass() and JVM_DefineClassWithSource()
// and JVM_DefineClassWithSourceCond()
static jclass jvm_define_class_common(JNIEnv *env, const char *name,
jobject loader, const jbyte *buf,
jsize len, jobject pd, const char *source,
jboolean verify, TRAPS) {
if (source == NULL)
source = "__JVM_DefineClass__";
OK，本文就记到这里吧。希望对问答频道提问那位同学有帮助。
Have fun ^_^
============================================================================
P.S. log里的"shared objects file"其实也是个有趣的话题。有机会的话也可以写写。
下载次数: 44
P.S. log里的"shared objects file"其实也是个有趣的话题。有机会的话也可以写写。 求该话题~
我的项目中出现java.lang.ClassNotFoundException: sun.reflect.GeneratedMethodAccessor27为什么啊？orz...还有这种事。请问有stack trace么？
constructorAccessor.newInstance(initargs);这行代码继续调用了一些方法，最后进入了MethodAccessorGenerator类的generate方法，又走到了ClassDefiner.defineClass(generatedName,bytes,0,bytes.length,declaringClass.getClassLoader()).newInstance()这一步，这难道不是一个死循环吗？呵呵呵呵，仔细点阅读代码的话就不会有这个疑问了。来，看这里：sun.reflect.ReflectionFactory// Bootstrapping issue: since we use Class.newInstance() in
// the ConstructorAccessor generation process, we have to
// break the cycle here.在为ConstructorAccessorImpl的子类的构造器创建constructor accessor的时候，并不像一般情况创建出包着NativeConstructorAccessorImpl的DelegatingConstructorAccessorImpl，而是创建出一个BootstrapConstructorAccessorImpl，后者不会再创建新的constructor accessor，就破掉循环了
里面的这段代码ClassDefiner.defineClass(generatedName,bytes,0,bytes.length,declaringClass.getClassLoader()).newInstance();又用newInstance()这个方法，这不是会导致死循环？请问java reflection到底是怎样work的？结合前面的例子，对A.foo()的反射调用做优化。generate()方法只是先根据需要造出了名为GeneratedMethodAccessor1的类，然后调用该类的newInstance()等同于new GeneratedMethodAccessor1()，这里是反射调用了一个新的类的构造器，与原本的A.foo()并没有关系。不知道什么地方看起来会有死循环呢？
你的头像导致我看了半天一直以为进了ns的blog。。蓝光满塞，BRS满塞～
RednaxelaFX
浏览: 1602827 次
来自: 海外
a11ght 写道我发现个问题，我在mac上禁用掉指针压缩，即 ...
a11ght 写道我发现个问题，我在mac上禁用掉指针压缩，即 ...
我发现个问题，我在mac上禁用掉指针压缩，即jdb -XX:- ...
不好用的说