I think you want to collect a call graph (as opposed to just a set of calls) by any means possible.
One can do with with a static analyzer (if you can get a strong enough one), to collect the potential call graph. A dynamic method collects one at runtime by instrumenting the code. Some folks may specifically want the dynamic one, because they want to see the actual call graph for a specific set of input data.
There are several Java profilers that will collect this information dynamically, including ours. None of the ones that do that are open source, that I know of, but I could be wrong.
Such profilers often work by instrumenting the code (either source or VM code if the language [e.g., Java,C#] has such). How they do it depends on the supplier. In our case, we use our program transformation tools to transform the source code from its original form, into a form that also collects profiling data.
You can use AspectJ to insert instrumentation to do this, too. [It is worth noting that aspects are just a special case of program transformation]. Of course, there's more work than just instrumenting the code; you have to collect the runtime data efficiently and after execution process to produce the call graph. So its rather a bit of work to do all this but you presumably know that from your Glow experience.
Maybe off-topic, but are you sure you want actually call graph? Somehow I think such a detailed graph will be next to useless in a reasonably sized application. What I find much more useful is a dependency graph between classes, one that is very easy to get as long as you use some kind of dependency injection. I used google guice (and it was actually pretty useful to restructure/keep clean a reasonably sized application).
There is a very nice google-guice-dependency grapher available out-of-the box and for free: http://code.google.com/p/google-guice/wiki/Grapher . I even customized it (extended the Grapher class) to mark different class types with different colors (DAO, controller, API etc.)...
发布评论
评论（3）
我认为您想通过任何可能的方式收集一个调用图（而不是一组调用）。
可以使用静态分析器（如果你能得到一个足够强大的分析器）来收集潜在的调用图。动态方法通过检测代码在运行时收集数据。有些人可能特别想要动态的，因为他们想查看一组特定输入数据的实际调用图。
有多个 Java 分析器可以动态收集此信息，包括我们的。据我所知，这样做的人都不是开源的，但我可能是错的。
此类分析器通常通过检测代码（源代码或 VM 代码，如果语言 [例如，Java、C#] 具有此类代码）来工作。他们如何做取决于供应商。
在我们的例子中，我们使用我们的程序转换工具将源代码从其原始形式，转换为还收集分析数据的形式。
您也可以使用 AspectJ 插入检测来执行此操作。 【值得注意的是，方面只是程序转换的一个特例】。当然，除了检测代码之外，还有更多的工作要做。您必须有效地收集运行时数据并在执行过程后生成调用图。因此，完成所有这些工作需要相当多的工作，但您可能从 Glow 体验中知道了这一点。
I think you want to collect a call graph (as opposed to just a set of calls) by any means possible.
One can do with with a static analyzer (if you can get a strong enough one), to collect the potential call graph. A dynamic method collects one at runtime by instrumenting the code. Some folks may specifically want the dynamic one, because they want to see the actual call graph for a specific set of input data.
There are several Java profilers that will collect this information dynamically, including ours. None of the ones that do that are open source, that I know of, but I could be wrong.
Such profilers often work by instrumenting the code (either source or VM code if the language [e.g., Java,C#] has such). How they do it depends on the supplier.
In our case, we use our program transformation tools to transform the source code from its original form, into a form that also collects profiling data.
You can use AspectJ to insert instrumentation to do this, too. [It is worth noting that aspects are just a special case of program transformation]. Of course, there's more work than just instrumenting the code; you have to collect the runtime data efficiently and after execution process to produce the call graph. So its rather a bit of work to do all this but you presumably know that from your Glow experience.
也许偏离主题，但你确定你真的想要调用图吗？不知何故，我认为如此详细的图表在大小合理的应用程序中几乎毫无用处。我发现更有用的是类之间的依赖关系图，只要使用某种依赖关系注入就很容易获得。我使用了 google guice（它实际上对于重组/保持合理大小的应用程序非常有用）。
有一个非常好的 google-guice-dependency 绘图器，开箱即用，免费：http://code.google.com/p/google-guice/wiki/Grapher 。我什至定制了它（扩展了 Grapher 类）以用不同的颜色标记不同的类类型（DAO、控制器、API 等）...
Maybe off-topic, but are you sure you want actually call graph? Somehow I think such a detailed graph will be next to useless in a reasonably sized application. What I find much more useful is a dependency graph between classes, one that is very easy to get as long as you use some kind of dependency injection. I used google guice (and it was actually pretty useful to restructure/keep clean a reasonably sized application).
There is a very nice google-guice-dependency grapher available out-of-the box and for free: http://code.google.com/p/google-guice/wiki/Grapher . I even customized it (extended the Grapher class) to mark different class types with different colors (DAO, controller, API etc.)...
通过本机 JVMTI C/C++
Java 确实有 Runtime.getRuntime().traceMethodCalls()，但您仍然需要一些东西来消耗输出。
There is instrumentation via the native JVMTI C/C++ native interfaces. Like I said I would like to stay in pure Java.
Java does have a Runtime.getRuntime().traceMethodCalls(), but you need something to consume the output still.