为什么自己写的java.lang.String不能代替jdk的被使用

原因：由类的加载器种类，加载器层级以及加载机制所决定

类加载器的种类

启动类加载器：负责加载JRE的核心类库，如jre目标下的rt.jar,charsets.jar等

扩展类加载器：负责加载JRE扩展目录ext中JAR类包 

系统类加载器：负责加载ClassPath路径下的类包 

用户自定义加载器：负责加载用户自定义路径下的类包

类加载器可分为两类：一是启动类加载器(Bootstrap ClassLoader)，是C++实现的，是JVM的一部分；另一种是其它的类加载器，是Java实现的，独立于JVM，全部都继承自抽象类java.lang.ClassLoader。jdk自带了三种类加载器，分别是启动类加载器（Bootstrap ClassLoader），扩展类加载器（Extension ClassLoader），应用程序（系统）类加载器（Application ClassLoader）。后两种加载器是继承自抽象类java.lang.ClassLoader。

类的加载机制

全盘负责委托机制：当一个ClassLoader加载一个类时，除非显示的使用另一个ClassLoader，该类所依赖和引用的类也由这个ClassLoader载入

双亲委派机制：指先委托父类加载器寻找目标类，在找不到的情况下再在子类加载器中去寻找加载。通俗的讲：如果一个类加载器收到了类加载的请求，它首先不会自己尝试去加载这个类，而是把这个请求委派给父类加载器，每一个层次的类加载器都是加此，因此所有的加载请求最终到达顶层的启动类加载器，只有当父类加载器反馈自己无法完成加载请求时（指它的搜索范围没有找到所需的类），子类加载器才会尝试自己去加载。

   双亲委派模式优势：

       沙箱安全机制：自己写的String.class类不会被加载，这样便可以防止核心API库被随意篡改 

       避免类的重复加载：当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次

类加载器层次关系

自定义类加载器 >> 应用程序类加载器 >> 扩展类加载器 >> 启动类加载器

如下例子输出各个类加载用到的类加载器：

自己写的java.lang.String运行结果如下：

package java.lang;

public class String {
    public static void main(String[] args) {
        System.out.println("张三");
    }
}