最近在使用Springboot的时候需要通过静态的方法获取到Spring容器托管的bean对象，参照一些博文里写的，新建了个类，并实现ApplicationContextAware接口。代码大致如下：

@Component
public class SpringUtils implements ApplicationContextAware {

    private static ApplicationContext applicationContext;

    @Override
    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
        if(SpringUtils.applicationContext == null) {
            SpringUtils.applicationContext = applicationContext;
        }
    }
   public static <T> T getBean(String name,Class<T> clazz){
        return getApplicationContext().getBean(name, clazz);
    }  
}

然后另外一个bean需要依赖这个静态获取bean的方法，代码大致如下：

@Component
public class TestBean{

   private Object dependencyBean = SpringUtils.getBean(OtherBean.class);  
    
}

（注： 忽略代码逻辑是否合理~~ 这些代码是为演示所用简化的逻辑，肯定有同学会说：既然都是bean了为什么不注入，而是要用静态的获取呢？这个暂时不考虑，暂认为就必须要这样搞）

这两个类的层次结构和包名大致如下： 

utils

> notice

　　> TestBean

> SpringUtils

就是TestBean在SpringUtils的下一级，TestBean所在包名为notice（这这个名字很重要！ 直接影响到这两个bean的加载顺序，具体原理往下看）

代码就这么多，从以上代码来静态分析看，确实有些漏洞，因为没有考虑到Spring bean的加载顺序，可能导致的SpringUtils报空指针异常（在TestBean先于SpringUtils初始化的场景下），不管怎么样先执行一下看下效果，效果如下：

macOS操作系统下代码正常

windows平台下代码空指针异常

为什么这还跟平台有关了呢？难道Spring bean的初始化顺序还跟平台有关？事实证明这个猜想是正确的。下面从Spring源代码里来找原因。

这里需要重点关注的类是 ConfigurationClassPostProcessor，这个类是干什么的？它从哪里来？如何实现bean的加载的？

在Spring里可以指定甚至自定义多个BeanFactoryPostProcessor来实现在实例化bean之前做一些bean容器的更新操作，比如修改某些bean的定义、增加一些bean、删除一些bean等，而ConfigurationClassPostProcessor就是Spring为了支持基于注解bean的功能而实现的BeanFactoryPostProcessor。

web环境的Springboot默认使用的应用上下文（ApplicationContext，BeanFactoryPostProcessor就是注册到这里才会起作用的）是AnnotationConfigEmbeddedWebApplicationContext，在AnnotationConfigEmbeddedWebApplicationContext的构造方法里初始化this.reader的时候，在reader的构造方法里把ConfigurationClassPostProcessor添加到ApplicationContext里了：

 

public class AnnotationConfigEmbeddedWebApplicationContext
        extends EmbeddedWebApplicationContext {

    private final AnnotatedBeanDefinitionReader reader;

    private final ClassPathBeanDefinitionScanner scanner;

    private Class<?>[] annotatedClasses;

    private String[] basePackages;

    /**
     * Create a new {@link AnnotationConfigEmbeddedWebApplicationContext} that needs to be
     * populated through {@link #register} calls and then manually {@linkplain #refresh
     * refreshed}.
     */
    public AnnotationConfigEmbeddedWebApplicationContext() {
        this.reader = new AnnotatedBeanDefinitionReader(this);  // 重点关注这句
        this.scanner = new ClassPathBeanDefinitionScanner(this);
    }

public class AnnotatedBeanDefinitionReader {

    private final BeanDefinitionRegistry registry;

    private BeanNameGenerator beanNameGenerator = new AnnotationBeanNameGenerator();

    private ScopeMetadataResolver scopeMetadataResolver = new AnnotationScopeMetadataResolver();

    private ConditionEvaluator conditionEvaluator;

    /**
     * Create a new {@code AnnotatedBeanDefinitionReader} for the given registry and using
     * the given {@link Environment}.
     * @param registry the {@code BeanFactory} to load bean definitions into,
     * in the form of a {@code BeanDefinitionRegistry}
     * @param environment the {@code Environment} to use when evaluating bean definition
     * profiles.
     * @since 3.1
     */
    public AnnotatedBeanDefinitionReader(BeanDefinitionRegistry registry, Environment environment) {
        Assert.notNull(registry, "BeanDefinitionRegistry must not be null");
        Assert.notNull(environment, "Environment must not be null");
        this.registry = registry;
        this.conditionEvaluator = new ConditionEvaluator(registry, environment, null);
        AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry); // 这里把ConfigurationClassPostProcessor注册到上下文里了
    }

上面介绍了Spring如何注册这个ConfigurationClassPostProcessor，下面看下这个类如何实现bean定义加载的。

public void processConfigBeanDefinitions(BeanDefinitionRegistry registry) {
        // ....
        // Parse each @Configuration class
        ConfigurationClassParser parser = new ConfigurationClassParser(
                this.metadataReaderFactory, this.problemReporter, this.environment,
                this.resourceLoader, this.componentScanBeanNameGenerator, registry);

        Set<BeanDefinitionHolder> candidates = new LinkedHashSet<BeanDefinitionHolder>(configCandidates);
        Set<ConfigurationClass> alreadyParsed = new HashSet<ConfigurationClass>(configCandidates.size());
        do {
            parser.parse(candidates);
            parser.validate();

            Set<ConfigurationClass> configClasses = new LinkedHashSet<ConfigurationClass>(parser.getConfigurationClasses());

主要的代码是 parser.parse(candidates); 这句，当执行到这里的时候candidates已经包含Springboot的配置类，这个parse会根据配置类里定义的basePackge递归扫描这个目录下面的class文件（如果没有定义basePackage字段则把配置类所在的包作为basePackage），debug跟踪代码到最底层可以看到使用的是PathMatchingResourcePatternResolver的doRetrieveMatchingFiles方法：

protected void doRetrieveMatchingFiles(String fullPattern, File dir, Set<File> result) throws IOException {
   if (logger.isDebugEnabled()) {
      logger.debug("Searching directory [" + dir.getAbsolutePath() +
            "] for files matching pattern [" + fullPattern + "]");
   }
   File[] dirContents = dir.listFiles();
   if (dirContents == null) {
      if (logger.isWarnEnabled()) {
         logger.warn("Could not retrieve contents of directory [" + dir.getAbsolutePath() + "]");
      }
      return;
   }
   Arrays.sort(dirContents);
   for (File content : dirContents) {
      String currPath = StringUtils.replace(content.getAbsolutePath(), File.separator, "/");
      if (content.isDirectory() && getPathMatcher().matchStart(fullPattern, currPath + "/")) {
         if (!content.canRead()) {
            if (logger.isDebugEnabled()) {
               logger.debug("Skipping subdirectory [" + dir.getAbsolutePath() +
                     "] because the application is not allowed to read the directory");
            }
         }
         else {
            doRetrieveMatchingFiles(fullPattern, content, result);
         }
      }
      if (getPathMatcher().match(fullPattern, currPath)) {
         result.add(content);
      }
   }
}

在这里可以看到有句 Arrays.sort(dirContents); 这个代码，就是在遍历一个文件夹下的资源时（包括文件夹和class文件），会先把资源排序一下，这个排序决定了bean的加载顺序！ 那再看下File（上面代码中的dirContents是File列表）是如何排序的：

public class File
    implements Serializable, Comparable<File>
{

    /**
     * The FileSystem object representing the platform's local file system.
     */
    private static final FileSystem fs = DefaultFileSystem.getFileSystem();


    /* -- Basic infrastructure -- */

    /**
     * Compares two abstract pathnames lexicographically.  The ordering
     * defined by this method depends upon the underlying system.  On UNIX
     * systems, alphabetic case is significant in comparing pathnames; on Microsoft Windows
     * systems it is not.
     *
     * @param   pathname  The abstract pathname to be compared to this abstract
     *                    pathname
     *
     * @return  Zero if the argument is equal to this abstract pathname, a
     *          value less than zero if this abstract pathname is
     *          lexicographically less than the argument, or a value greater
     *          than zero if this abstract pathname is lexicographically
     *          greater than the argument
     *
     * @since   1.2
     */
    public int compareTo(File pathname) {
        return fs.compare(this, pathname);
    }

使用的是FileSystem的排序方法，再看看DefaultFileSystem.getFileSystem();拿到是是什么：

mac下：

/**
 *
 * @since 1.8
 */
class DefaultFileSystem {

    /**
     * Return the FileSystem object for Unix-based platform.
     */
    public static FileSystem getFileSystem() {
        return new UnixFileSystem();
    }
}
// UnixFileSystem

class UnixFileSystem extends FileSystem {

/* -- Basic infrastructure -- */

public int compare(File f1, File f2) {
return f1.getPath().compareTo(f2.getPath());
}

}

windows下：

/**
 *
 * @since 1.8
 */
class DefaultFileSystem {

    /**
     * Return the FileSystem object for Windows platform.
     */
    public static FileSystem getFileSystem() {
        return new WinNTFileSystem();
    }
}
//WinNTFileSystem

@Override
public int compare(File f1, File f2) {
return f1.getPath().compareToIgnoreCase(f2.getPath());
}

由于windows下和mac下使用的FileSystem不同，jdk windows版FileSystem实现的compare方法在比较文件是忽略了文件名的大小写，而mac版没有忽略大小写，所以导致前面提出的同样的代码在windows下报错，在mac下就是正常的问题。

但是为什么会有这样的差别呢？不是太明白为什么

那还剩最后一个问题，这个问题如何解决呢？我这有两个方法，一是修改类名让被依赖的类排在前面，这种方法不是太优雅，而且如果以后jdk更新了排序方法可能还会出bug，第二种是在使用类上加DependOn注解，主动说明在初始化使用类时首先加载被依赖的类，这样就没有问题了，但是我感觉在开发的时候尽量避免这种依赖问题，这让容器和业务代码参杂，以后维护是个噩梦

包括英文版本和中文版本两种的说明, 特别需要值得一提的是那个 -nl 参数, 可以指定程序启动时所使用的语言. 例如:

eclipse -nl en_US
将启动英文语言, 这个特性在安装了国际化语言包以后特别有用, 可以方便的切换各个语言的版本. 注意 IBM WSAD v5.1 也支持这个功能.

运行 Eclipse

将 Eclipse 驱动程序安装（解压缩）到某个目录（例如，c:\eclipse）中之后，通过运行顶级安装目录中的 Eclipse 可执行文件来启动"工作台"。在 Windows 系统上，该可执行文件称为 eclipse.exe，而在 Linux 系统上称为 eclipse。注意：下列讨论描述 Windows 系统上的设置。Linux 上的设置是相似的。

如果您没有另行指定，则平台将缺省工作区目录创建为可执行文件的兄弟目录（例如 c:\eclipse\workspace）。此工作区目录用作项目的缺省内容区，还用于保存任何必需的元数据。要进行共享安装或多工作区安装，应明确指出工作区的位置而不是使用缺省值。有两种控制工作区位置的方法：使用当前工作目录或使用 -data 命令行自变量。

将工作区位置设置为在当前工作目录内

在此方案中，工作区位置将是当前工作目录中称为 workspace 的目录。

实现此目的最容易的方法可能是使用下列步骤来创建快捷方式：

1. 导航到 Windows 资源管理器中的 eclipse.exe 并使用右键拖动来创建 eclipse.exe 的快捷方式。
2. 编辑快捷方式的属性，以使启动位置：字段标识工作区位置的父目录（例如，c:\users\robert）。
3. 关闭属性对话框并双击快捷方式（如果提供的目录为 c:\users\robert，则工作区位置将为 c:\users\robert\workspace）。

当然，您也可以使用命令提示符（通过将目录切换为工作区父目录然后运行 eclipse.exe）来获得同样的效果。

使用 -data 设置工作区的特定位置

要使用 -data 命令行自变量，只要将 -data your_workspace_location（例如，-data c:\users\robert\myworkspace）添加至快捷方式属性中的目标字段或显式地将它包括在命令行上。

使用 -vm 设置 java VM

建议显式指定在运行 Eclipse 时要使用哪个 Java VM。使用 -vm 命令行自变量（例如，-vm c:\jre\bin\javaw.exe）可以实现此目的。如果不使用 -vm，则 Eclipse 将使用在 O/S 路径上找到的一个 Java VM。当安装其它产品时，它们可更改您的路径，导致在下一次启动 Eclipse 时使用另一 Java VM。

运行 Eclipse 中的高级主题

Eclipse 可执行文件及平台本身提供了人们感兴趣的开发或调试 Eclipse 各部件的许多执行选项。运行 Eclipse 可执行文件的一般格式是：

eclipse [platform options] [-vmargs [Java VM arguments]]

<>Eclipse 启动参数 <>命令 描述

-arch architecture

-application applicationId

-boot bootJarURL

-classloaderproperties [file]

-configuration configurationFileURL

-consolelog

-data workspacePath

-debug [optionsFile]

-dev [classpathEntries]

-endsplash params

-feature featureId

-keyring keyringFilePath

-nl locale

-nolazyregistrycacheloading

-noregistrycache

-nosplash

-os operatingSystem

-password password

-perspective perspectiveId

-plugincustomization
	  propertiesFile

-plugins pluginsFileURL

-refresh

-showlocation

-showsplash params

-vm vmPath

-ws windowSystem

将 -vmargs 条目后面的所有自变量（但不包括 -vmargs）作为虚拟机自变量（即，在要运行的类的前面）直接传递到所指示的 Java VM。注意：如果 Eclipse 启动在 Java vm 自变量（-vmargs）之后提供的自变量（例如，-data），则 Eclipse 将不会启动并且您将接收到"JVM 已终止。出口代码为 1"的错误。

在不同的 VM 上运行

在 J9 上运行 Eclipse

当在 J9 版本 1.5 上运行 Eclipse 时，建议使用以下 VM 选项：

eclipse.exe [eclipse arguments] -vm path_to_j9w.exe 
            -vmargs -ms:32 -mm:2048 -mo:32768 -moi:32768 -mca:32 -mco:128 -mx:2000000

当在 J9 版本 2.0 上运行 Eclipse 时，J9W 选择的缺省自变量应为合适的选项。但是，要覆盖 Eclipse 可执行文件以内部方式自动设置的参数，必须指定 -vmargs 不带任何参数，如下所示：

eclipse.exe [eclipse arguments] -vm path_to_j9w.exe -vmargs

有关进一步信息，参考 J9 VM 文档和帮助。

在 IBM Developer Kit, Java(TM) Technology Edition VM 上运行 Eclipse

IBM Developer Kit, Java(TM) Technology Edition 1.3 Linux 的缺省 VM 设置适合进行初期研究工作，但在进行大型开发时是不够的。对于大型开发，应修改 VM 自变量以使有更多的堆可用。例如，下列设置将允许 Java 堆增大为 256MB：

-vmargs -Xmx256M

Running Eclipse

After you install (unzip) the Eclipse driver in a directory (such as c:\eclipse), start the Workbench by running the Eclipse executable file found in the top level install directory. The executable file is called eclipse.exe on Windows systems and eclipse on Linux systems. Note: the following discussion describes setting up on Windows systems. Setup on Linux is analogous.

If you do not specify otherwise, the platform creates a default workspace directory as a sibling of the executable (for example, c:\eclipse\workspace). This workspace directory is used as the default content area for your projects as well as for holding any required metadata. For shared or multi-workspace installs you should explicitly state the location of your workspace rather than using the default. There are two ways to control the location of your workspace: using the current working directory or using the -data command line argument.

Setting the workspace location to be inside the current working directory

In this scenario, the workspace location will be a directory called workspace inside the current working directory.

Perhaps the easiest way of doing this is to create a shortcut using the following steps:

1. Navigate to eclipse.exe in the Windows Explorer and using a right button drag, create a shortcut to eclipse.exe.
2. Edit the properties of the shortcut such that the Start in: field identifies the parent directory of your workspace location (for example, c:\users\robert).
3. Close the properties dialog and double-click on the shortcut (if the provided directory was c:\users\robert, the workspace location would be c:\users\robert\workspace).

Of course you can get the same effect using a command prompt by changing directory to your workspace parent's directory and then running eclipse.exe.

Setting a specific location for the workspace with -data

To use the -data command line argument, simply add -data your_workspace_location (for example, -data c:\users\robert\myworkspace) to the Target field in the shortcut properties, or include it explicitly on your command line.

Setting the java VM using -vm

It is recommended that you explicitly specify which Java VM to use when running Eclipse. This is achieved with the -vm command line argument (for example, -vm c:\jre\bin\javaw.exe). If you don't use -vm, Eclipse will use the first Java VM found on the O/S path. When you install other products, they may change your path, resulting in a different Java VM being used when you next launch Eclipse.

Advanced Topics in Running Eclipse

The Eclipse executable and the platform itself offer a number of execution options of interest to people developing or debugging parts of Eclipse. The general form of running the Eclipse executable is:

eclipse [platform options] [-vmargs [Java VM arguments]]

<>Eclipse Startup Parameters <>Command Description

-arch architecture

-application applicationId

-boot bootJarURL

-classloaderproperties [file]

-configuration configurationFileURL

-consolelog

-data workspacePath

-debug [optionsFile]

-dev [classpathEntries]

-endsplash params

-feature featureId

-keyring keyringFilePath

-nl locale

-nolazyregistrycacheloading

-noregistrycache

-nosplash

-os operatingSystem

-password password

-perspective perspectiveId

-plugincustomization
	  propertiesFile

-plugins pluginsFileURL

-refresh

-showlocation

-showsplash params

-vm vmPath

-ws windowSystem

All arguments following (but not including) the -vmargs entry are passed directly through to the indicated Java VM as virtual machine arguments (that is, before the class to run). Note: If an Eclipse startup argument, such as -data, is provided after the Java vm arguments (-vmargs), Eclipse will not start and you will receive a "JVM terminated. Exit code=1" error.

Running on Different VMs

Running Eclipse on J9

When running Eclipse on J9 version 1.5, it is recommended that you use the following VM options:

eclipse.exe [eclipse arguments] -vm path_to_j9w.exe 
            -vmargs -ms:32 -mm:2048 -mo:32768 -moi:32768 -mca:32 -mco:128 -mx:2000000

When running Eclipse on J9 version 2.0, the default arguments chosen by J9W should be suitable. However, to override the parameters which are automatically set internally by the Eclipse executable, you must specify -vmargs with no following arguments as follows:

eclipse.exe [eclipse arguments] -vm path_to_j9w.exe -vmargs

Please refer to the J9 VM documentation and help for further information.

Running Eclipse on the IBM Developer Kit, Java(TM) Technology Edition VM

The default VM settings for IBM Developer Kit, Java(TM) Technology Edition 1.3 Linux work well for initial exploration, but are not sufficient for large scale development. For large scale development you should modify your VM arguments to make more heap available. For example, the following setting will allow the Java heap to grow to 256MB:

-vmargs -Xmx256M

来源： https://www.cnblogs.com/sunsonbaby/archive/2005/02/02/101112.html