GetPropertyAction与System.getProperty获取系统变量 [英] GetPropertyAction vs System.getProperty in obtaining system variables

问题描述

我一直在使用相当多的

System.getProperty("property")

以获取环境信息。但是，在我看来，Sun喜欢以下内容：

in order to obtain environmental information. However, it seems to me that Sun prefers the following :

(String) java.security.AccessController.doPrivileged(
               new sun.security.action.GetPropertyAction("property"));

奇怪的是，这段代码涉及到一个转换，结果应该比

The strange thing is that this code involves a cast and as a result should be slightly slower than the

System.getProperty

实现，只使用然后立即从实例变量道具中获取属性。我的问题是为什么Sun选择使用第二种方法在内部获取代码中的大多数环境变量，而

implementation, that only uses a security manager and then instantly fetches the property from the instance variable props. My question is why did Sun chose to use the second method to obtain most environmental variables in their code internally, while

System.getProperty

System.getProperty

推荐答案

p>这两种方法都有不同的含义，因此根据当前的代码需要使用正确的方法。

Both methods have a different meaning, and thus the right one has to be used depending on what the current code needs to do.

代码 System.getProperty（property）说给我的属性的价值，如果当前的安全上下文允许我阅读它。

The code System.getProperty("property") says "Give me the value of the property, if the current security context allows me to read it."

使用 doPrivileged 的代码说：如果允许当前类（该代码行在哪里））读取该属性，请给我属性的值。

The code that uses doPrivileged says "Give me the value of the property, if the current class (where this line of code is in) is allowed to read it."

当当前类的保护域与当前活动的安全上下文不同时，差异就起作用。

The difference comes into play, when the protection domain of the current class is different from the currently active security context.

例如，考虑一个执行插件代码的框架，这是不信任的。因此，框架使用SecurityManager来限制不受信任的插件代码的操作。但是当然插件可能会调用框架的一些方法，并且假设这些方法之一需要读取一个属性。现在，由于不受信任的限制代码调用该方法，它本身受到限制，因此读属性将失败。但是，当然，框架信任自己，并希望自己能够读取该属性，即使在调用堆栈中的某个位置是不受信任的代码的情况。那就是当你需要使用 doPrivileged 。它基本上说无论在调用堆栈中有什么，我是一个框架代码，我被允许做任何框架代码被允许做。所以使用第二种方法读取属性成功。

For example, consider a framework which executes the code of a plugin, which is untrusted. So the framework uses a SecurityManager to restrict the actions of the untrusted plugin code. But of course the plugin may call some methods of the framework, and suppose that one of these methods needs to read a property. Now as the method is called from untrusted restricted code, it is itself restricted and thus reading the property would fail. But of course the framework trusts itself and wants itself to be able to read that property, even in the case that somewhere in the call stack is untrusted code. That's when you need to use doPrivileged. It basically says "no matter what is up there in the call stack, I am a piece of framework code, and I am allowed to do whatever the framework code is allowed to do". So reading the property using the second method succeeds.

当然，使用 doPrivileged 时需要小心不要让（不可信）的调用代码做得很多。例如，如果框架代码为插件提供了以下方法：

Of course one needs to be careful when using doPrivileged in order to not let the (untrusted) calling code do to much. If, for example, the framework code offers the following method to the plugin:

public String getProp(String key) {
  return (String) java.security.AccessController.doPrivileged(
           new sun.security.action.GetPropertyAction(key));
}

这将完全无效不可信代码不允许读取系统的策略属性，因为它只能使用你的方法。

this would completely invalidate the policy that the untrusted code is not allowed to read system properties, because it can just use your method.

所以只有当你知道它是安全的，只有当你需要它（这是，当你希望你的代码能够做一些其他的代码应该能够直接做）。在正常的应用程序中（通常运行没有SecurityManager或所有代码的相同的安全上下文），没有区别，应该使用第一种方法。

So use this method only when you know it is safe to do it, and only when you need it (which is, when you want your code to be able to do more than some other code should be able to do directly). Inside a normal application (which usually runs with no SecurityManager or the same security context for all code), there is no difference and the first method should be used.

这篇关于GetPropertyAction与System.getProperty获取系统变量的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！