精华内容
下载资源
问答
  • 易语言源码易语言线程上下文注入源码.rar 易语言源码易语言线程上下文注入源码.rar 易语言源码易语言线程上下文注入源码.rar 易语言源码易语言线程上下文注入源码.rar 易语言源码易语言线程上下文注入源码.rar ...
  • 线程上下文切换

    千次阅读 2018-08-29 10:05:04
    一、为什么要减少线程上下文切换  当CPU从执行一个线程切换到执行另外一个线程的时候,它需要先存储当前线程的本地的数据,程序指针等,然后载入另一个线程的本地数据,程序指针等,最后才开始执行。这种切换称为...

                一、为什么要减少线程上下文切换
                    当CPU从执行一个线程切换到执行另外一个线程的时候,它需要先存储当前线程的本地的数据,程序指针等,然后载入另一个线程的本地数据,程序指针等,最后才开始执行。这种切换称为“上下文切换”(“context switch”)。CPU会在一个上下文中执行一个线程,然后切换到另外一个上下文中执行另外一个线程。上下文切换并不廉价,是比较耗时的
                二、线程上下文切换发生的条件
                    1.中断处理:中断分为硬件中断和软件中断,软件中断包括因为IO阻塞、未抢到资源或者用户代码等原因,线程被挂起
                    2.多任务处理:每个程序都有相应的时间处理片,当前任务的时间片用完之后,系统CPU正常调度下一个任务
                    3.用户状态切换:这种情况下,上下文切换并非一定发生,只在特定操作系统才会发生上下文切换
                三、上下文切换的步骤
                    1.为了理解为什么上下文切换的时候会损耗性能,我们应该先看看上下文切换的过程中究竟发生了什么。在切换过程中,正在执行的进程的状态必须以某种方式存储起来,这样在未来才能被恢复。这里说的进程状态包括该进程正在使用的所有寄存器(尤其是程序计数器),和一些必要的操作系统数据。保存进程状态的数据结构叫做“进程控制块”(PCB,process control block);
                    2.PCB通常是系统内存占用区中的一个连续存区,它存放着操作系统用于描述进程情况及控制进程运行所需的全部信息,它使一个在多道程序环境下不能独立运行的程序成为一个能独立运行的基本单位或一个能与其他进程并发执行的进程。
                    上下文切换的具体步骤是(假设当前进程是进程A,要切换到的下一个进程是进程B):
                        1.保存进程A的状态(寄存器和操作系统数据);
                        2.更新PCB中的信息,对进程A的“运行态”做出相应更改;
                        3.将进程A的PCB放入相关状态的队列;
                        4.将进程B的PCB信息改为“运行态”,并执行进程B;
                        5.B执行完后,从队列中取出进程A的PCB,恢复进程A被切换时的上下文,继续执行A。
                        6.线程分为用户级线程和内核级线程。同一进程中的用户级线程切换的时候,只需要保存用户寄存器的内容,程序计数器,栈指针,不需要模式切换。但是这样会导致线程阻塞和无法利用多处理器。而同一进程中的内核级线程切换的时候,就克服了这两个缺点,但是除了保存上下文,还要进行模式切换。
                    线程切换和进程切换的步骤不同。进程的上下文切换分为两步:1.切换页目录以使用新的地址空间;2.切换内核栈和硬件上下文。对于linux来说,线程和进程的最大区别就在于地址空间。对于线程切换,第1步是不需要做的,第2是进程和线程切换都要做的。所以明显是进程切换代价大。线程上下文切换和进程上下文切换一个最主要的区别是线程的切换虚拟内存空间依然是相同的,但是进程切换是不同的。这两种上下文切换的处理都是通过操作系统内核来完成的。内核的这种切换过程伴随的最显著的性能损耗是将寄存器中的内容切换出。
                四、如何减少线程上下文切换
                        1.无锁并发编程:多线程竞争锁时,会引起上下文切换,所以多线程处理数据时,可以用一些办法来避免使用锁,如将数据的ID按照Hash算法取模分段,不同的线程处理不同段的数据。 
                        2.CAS算法:Java的Atomic包使用CAS(compare and swap)算法来更新数据,而不需要加锁。 
                        3.使用最少线程:避免创建不需要的线程,比如任务很少,但是创建了很多线程来处理,这样会造成大量线程都处于等待状态。 
                        4.协程:在单线程里实现多任务的调度,并在单线程里维持多个任务间的切换。

    一、上下文切换
        1.即使是单核处理器也支持多线程执行代码,CPU通过给每个线程分配CPU时间片来实现这个机制。时间片是CPU分配给各个线程的时间,因为时间片非常短,所以CPU通过不停的切换线程执行,让我们感觉多个线程是同时执行的,时间片一般是几十毫秒。
        2.CPU通过时间片分配算法来循环执行任务,当前任务执行一个时间片后会切换到下一个任务。但是在切换之前会保存上一个任务的状态,以便下次切换回这个任务时,可以再加载这个任务的状态。所以任务从保存到再加载的过程就是一次上下文切换。
    二、多线程并不一定快
    三、测试上下文切换的次数和时长
        1.通过Lmbench3测量上下文切换的次数
        2.通过vmstat测量上下文切换的次数
    五、避免死锁的常见方法
        1.避免一个线程同时获取多个锁
        2.避免一个线程在锁内同时占用多个资源
        3.尝试使用定时锁,使用lock.tryLock(timeout)来替代使用内部锁机制
        4.对于数据库锁,加锁和解锁必须在一个数据库连接中,否则会出现解锁失败的情况
    六、资源限制的挑战
        1.什么是资源限制:资源限制是指在进行并发编程的时候,程序的执行速度受限于计算机硬件资源或软件资源。例如:硬件资源限制有带宽的上传和下载速度、硬盘读写速度和CPU的处理速度,软件资源限制有数据库的连接数和socket连接数等
        2.资源限制引起的问题:在并发编程中,将代码执行速度加快的原则是将代码中串行执行的部分变为并发执行,但是如果将某段串行的代码并发执行,因为受限于资源,仍然在串行执行,这个时候系统性能反而会变慢,因为增加了上下文切换和资源调度的时间。
        3.如何解决资源限制的问题:对于硬件资源限制,可以考虑使用资源池将资源服用。
        4.在资源限制下进行并发编程:如何在资源限制的情况下,让程序执行的更快呢?根据不同的资源限制调整程序的并发度。

    展开全文
  • 易语言线程上下文注入源码
  • jvm之线程上下文加载器与SPI

    万次阅读 2020-07-11 19:05:57
    线程上下文加载器 线程上下文类加载器(Thread Context Class Loader,简称TCCL)是从JDK1.2开始引入的。类java.lang.Thread中的方法getContextClassLoader()和setContextClassLoader(ClassLoader cl)用来获取和设置...

    线程上下文加载器

    线程上下文类加载器(Thread Context Class Loader,简称TCCL)是从JDK1.2开始引入的。类java.lang.Thread中的方法getContextClassLoader()和setContextClassLoader(ClassLoader cl)用来获取和设置线程的上下文类加载器。

    如果没有通过setContextClassLoader(ClassLoader cl)方法进行设置的话,线程将继承其父线程的上下文类加载器,默认为系统类加载器,这点可以从下面的JDK中的源码中得到验证。

    以下代码摘自sun.misc.Launch的无参构造函数Launch():

    public Launcher() {
        Launcher.ExtClassLoader var1;
        try {
            var1 = Launcher.ExtClassLoader.getExtClassLoader();
        } catch (IOException var10) {
            throw new InternalError("Could not create extension class loader", var10);
        }
    
        try {
            this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
        } catch (IOException var9) {
            throw new InternalError("Could not create application class loader", var9);
        }
    
        Thread.currentThread().setContextClassLoader(this.loader);
    ...
    

    SPI

    Service Provider Interface:服务提供者接口,简称SPI,是Java提供的一套用来被第三方实现或者扩展的API。常见的SPI有JDBC、JNDI、JAXP等,这些SPI的接口由Java核心库实现,而这些SPI的具体实现由第三方jar包实现。

    下面先看一段经典的JDBC获取连接的代码:

    // Class.forName("com.mysql.jdbc.Driver").newInstance();
    Connection conn = java.sql.DriverManager.getConnection("jdbc:mysql://localhost:3306/test", "root", "root");
    

    我们可以Class.forName这一行被注释掉了,但依然可以正常运行,这是为什么呢?

    下面通过跟踪源码一步一步分析原因:

    先看DriverManager这个类,调用该类的静态方法getConnection(),就会导致该类的初始化,也就是会执行这个类的静态代码块,DriverManager的静态代码块如下:

        // 静态代码块
        static {
            loadInitialDrivers();
            println("JDBC DriverManager initialized");
        }
        
        // 加载驱动
        private static void loadInitialDrivers() {
            ...
    
            AccessController.doPrivileged(new PrivilegedAction<Void>() {
                public Void run() {
    
                    // 读取 META-INF/services
                    ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
                    Iterator<Driver> driversIterator = loadedDrivers.iterator();
    
                    try{
                        while(driversIterator.hasNext()) {
                            // next()的时候才会去加载
                            driversIterator.next();
                        }
                    } catch(Throwable t) {
                    // Do nothing
                    }
                    return null;
                }
            });
            ... 
        }
    

    再来看一下ServiceLoader.load方法:

        public static <S> ServiceLoader<S> load(Class<S> service) {
            ClassLoader cl = Thread.currentThread().getContextClassLoader();
            return ServiceLoader.load(service, cl);
        }
    

    从load方法中可以看出取出了线程上下文加载器也就是系统类加载器传递给了后面的代码。

    一路跟踪下去会发现系统类加载这个参数传给了里面的一个内部类LazyIterator:

        private class LazyIterator
            implements Iterator<S>
        {
    
            Class<S> service;
            ClassLoader loader; // 系统类加载器
            Enumeration<URL> configs = null;
            Iterator<String> pending = null;
            String nextName = null;
    
            private LazyIterator(Class<S> service, ClassLoader loader) {
                this.service = service;
                this.loader = loader;
            }
    

    LazyIterator实现了Iterator接口,后面loadInitialDrivers中获取这个迭代器进行遍历,最终会调用下面的两个方法

            private boolean hasNextService() {
                if (nextName != null) {
                    return true;
                }
                if (configs == null) {
                    try {
                        // META-INF/services/ + java.sql.Driver
                        String fullName = PREFIX + service.getName();
                        if (loader == null)
                            configs = ClassLoader.getSystemResources(fullName);
                        else
                            configs = loader.getResources(fullName);
                    } catch (IOException x) {
                        fail(service, "Error locating configuration files", x);
                    }
                }
                while ((pending == null) || !pending.hasNext()) {
                    if (!configs.hasMoreElements()) {
                        return false;
                    }
                    // 解析META-INF/services/java.sql.Driver文件
                    pending = parse(service, configs.nextElement());
                }
                nextName = pending.next();
                return true;
            }
    
            private S nextService() {
                if (!hasNextService())
                    throw new NoSuchElementException();
                String cn = nextName;
                nextName = null;
                Class<?> c = null;
                try {
                    // 使用线程上下文加载器加载META-INF/services/java.sql.Driver中指定的驱动类
                    c = Class.forName(cn, false, loader);
                } catch (ClassNotFoundException x) {
                    fail(service,
                         "Provider " + cn + " not found");
                }
                if (!service.isAssignableFrom(c)) {
                    fail(service,
                         "Provider " + cn  + " not a subtype");
                }
                try {
                    S p = service.cast(c.newInstance());
                    providers.put(cn, p);
                    return p;
                } catch (Throwable x) {
                    fail(service,
                         "Provider " + cn + " could not be instantiated",
                         x);
                }
                throw new Error();          // This cannot happen
            }
    

    再来看一下mysql-connector-java.jar包下META-INF/services/java.sql.Driver中内容:

    com.mysql.jdbc.Driver
    com.mysql.fabric.jdbc.FabricMySQLDriver
    

    最后看一下com.mysql.jdbc.Driver的静态代码块:

    static {
            try {
                DriverManager.registerDriver(new Driver());
            } catch (SQLException var1) {
                throw new RuntimeException("Can't register driver!");
            }
        }
    

    registerDriver方法将driver实例注册到JDk的java.sql.DriverManager类中,其实就是add到它的一个类型为CopyOnWriteArrayList,名为registeredDrivers的静态属性中,到此驱动注册基本完成,

    总结:如果我们使用JDBC时没有主动使用Class.forName加载mysql的驱动时,那么JDBC会使用SPI机制去查找所有的jar下面的META-INF/services/java.sql.Driver文件,使用Class.forName反射加载其中指定的驱动类。

    DriverManager类和ServiceLoader类都是属于rt.jar的,它们的类加载器是根类加载器。而具体的数据库驱动,却属于业务代码,这个根类加载器是无法加载的。而线程上下文类加载器破坏了“双亲委派模型”,可以在执行线程中抛弃双亲委派加载链模式,使程序可以逆向使用类加载器。

    使用TCCL校验实例的归属

    下面再来看一下java.sql.DriverManager.getConnection()这个方法,这里面有个小细节:

        //  Worker method called by the public getConnection() methods.
        private static Connection getConnection(
            String url, java.util.Properties info, Class<?> caller) throws SQLException {
    
            // callerCL是调用这个方法的类所对应的类加载器
            ClassLoader callerCL = caller != null ? caller.getClassLoader() : null;
            synchronized(DriverManager.class) {
                // synchronize loading of the correct classloader.
                if (callerCL == null) {
                    callerCL = Thread.currentThread().getContextClassLoader();
                }
            }
            ...
            // 遍历注册到registeredDrivers里的Driver类
            for(DriverInfo aDriver : registeredDrivers) {
                // 使用线程上下文类加载器检查Driver类有效性,重点在isDriverAllowed中,方法内容在后面
                if(isDriverAllowed(aDriver.driver, callerCL)) {
                    try {
                        println("    trying " + aDriver.driver.getClass().getName());
                        Connection con = aDriver.driver.connect(url, info);
                        if (con != null) {
                            // Success!
                            println("getConnection returning " + aDriver.driver.getClass().getName());
                            return (con);
                        }
                    } catch (SQLException ex) {
                        if (reason == null) {
                            reason = ex;
                        }
                    }
    
                } else {
                    println("    skipping: " + aDriver.getClass().getName());
                }
    
            }
            ...
        }
    
        private static boolean isDriverAllowed(Driver driver, ClassLoader classLoader) {
            boolean result = false;
            if(driver != null) {
                Class<?> aClass = null;
                try {
                    // 传入的classLoader为调用getConnetction的线程上下文类加载器,使用这个类加载器再次加载驱动类
                    aClass =  Class.forName(driver.getClass().getName(), true, classLoader);
                } catch (Exception ex) {
                    result = false;
                }
                // 这里只有aClass和driver.getClass()是由同一个类加载器加载才会相等
                 result = ( aClass == driver.getClass() ) ? true : false;
            }
    
            return result;
        }
    

    isDriverAllowed这个方法的意义:例如在tomcat中,多个webapp都有自己的Classloader,如果它们都自带mysql-connect.jar包,那底层Classloader的DriverManager里将注册多个不同类加载器加载的Driver实例,webapp想要从DriverManager中获得连接,只有通过线程上下文加载器区分了。

    更多精彩内容关注本人公众号:架构师升级之路
    在这里插入图片描述

    展开全文
  • 1 线程上下文类加载器 2 何时使用Thread.getContextClassLoader()? 3 类加载器与Web容器 4 类加载器与OSGi 总结 1 线程上下文类加载器  线程上下文类加载器(context class loader)是从 JDK 1.2 开始引入的...

    目录

    1 线程上下文类加载器

    2 何时使用Thread.getContextClassLoader()?

    3 类加载器与Web容器

    4 类加载器与OSGi

    总结


    1 线程上下文类加载器

      线程上下文类加载器(context class loader)是从 JDK 1.2 开始引入的。类 java.lang.Thread中的方法 getContextClassLoader()和 setContextClassLoader(ClassLoader cl)用来获取和设置线程的上下文类加载器。如果没有通过 setContextClassLoader(ClassLoader cl)方法进行设置的话,线程将继承其父线程的上下文类加载器。Java 应用运行的初始线程的上下文类加载器是系统类加载器。在线程中运行的代码可以通过此类加载器来加载类和资源。
      前面提到的类加载器的代理模式并不能解决 Java 应用开发中会遇到的类加载器的全部问题。Java 提供了很多服务提供者接口(Service Provider Interface,SPI),允许第三方为这些接口提供实现。常见的 SPI 有 JDBC、JCE、JNDI、JAXP 和 JBI 等。这些 SPI 的接口由 Java 核心库来提供,如 JAXP 的 SPI 接口定义包含在 javax.xml.parsers包中。这些 SPI 的实现代码很可能是作为 Java 应用所依赖的 jar 包被包含进来,可以通过类路径(CLASSPATH)来找到,如实现了 JAXP SPI 的 Apache Xerces所包含的 jar 包。SPI 接口中的代码经常需要加载具体的实现类。如 JAXP 中的 javax.xml.parsers.DocumentBuilderFactory类中的 newInstance()方法用来生成一个新的 DocumentBuilderFactory的实例。这里的实例的真正的类是继承自 javax.xml.parsers.DocumentBuilderFactory,由 SPI 的实现所提供的。如在 Apache Xerces 中,实现的类是 org.apache.xerces.jaxp.DocumentBuilderFactoryImpl。而问题在于,SPI 的接口是 Java 核心库的一部分,是由引导类加载器来加载的;SPI 实现的 Java 类一般是由系统类加载器来加载的。引导类加载器是无法找到 SPI 的实现类的,因为它只加载 Java 的核心库。它也不能代理给系统类加载器,因为它是系统类加载器的祖先类加载器。也就是说,类加载器的代理模式无法解决这个问题。
      线程上下文类加载器正好解决了这个问题。如果不做任何的设置,Java 应用的线程的上下文类加载器默认就是系统上下文类加载器。在 SPI 接口的代码中使用线程上下文类加载器,就可以成功的加载到 SPI 实现的类。线程上下文类加载器在很多 SPI 的实现中都会用到。
      Java默认的线程上下文类加载器是系统类加载器(AppClassLoader)。以下代码摘自sun.misc.Launch的无参构造函数Launch()。

    // Now create the class loader to use to launch the application
    try {
        loader = AppClassLoader.getAppClassLoader(extcl);
    } catch (IOException e) {
        throw new InternalError(
    "Could not create application class loader" );
    }
    
    
    // Also set the context class loader for the primordial thread.
    Thread.currentThread().setContextClassLoader(loader);

      使用线程上下文类加载器,可以在执行线程中抛弃双亲委派加载链模式,使用线程上下文里的类加载器加载类。典型的例子有:通过线程上下文来加载第三方库jndi实现,而不依赖于双亲委派。大部分java application服务器(jboss, tomcat..)也是采用contextClassLoader来处理web服务。还有一些采用hot swap特性的框架,也使用了线程上下文类加载器,比如 seasar (full stack framework in japenese)。
      线程上下文从根本解决了一般应用不能违背双亲委派模式的问题。使java类加载体系显得更灵活。随着多核时代的来临,相信多线程开发将会越来越多地进入程序员的实际编码过程中。因此,在编写基础设施时, 通过使用线程上下文来加载类,应该是一个很好的选择。
      当然,好东西都有利弊。使用线程上下文加载类,也要注意保证多个需要通信的线程间的类加载器应该是同一个,防止因为不同的类加载器导致类型转换异常(ClassCastException)。
      defineClass(String name, byte[] b, int off, int len,ProtectionDomain protectionDomain)是java.lang.Classloader提供给开发人员,用来自定义加载class的接口。使用该接口,可以动态的加载class文件。例如在jdk中,URLClassLoader是配合findClass方法来使用defineClass,可以从网络或硬盘上加载class。而使用类加载接口,并加上自己的实现逻辑,还可以定制出更多的高级特性。
      下面是一个简单的hot swap类加载器实现。hot swap即热插拔的意思,这里表示一个类已经被一个加载器加载了以后,在不卸载它的情况下重新再加载它一次。我们知道Java缺省的加载器对相同全名的类只会加载一次,以后直接从缓存中取这个Class object。因此要实现hot swap,必须在加载的那一刻进行拦截,先判断是否已经加载,若是则重新加载一次,否则直接首次加载它。我们从URLClassLoader继承,加载类的过程都代理给系统类加载器URLClassLoader中的相应方法来完成。

    package classloader;
    
    
    import java.net.URL;
    import java.net.URLClassLoader;
    
    
    /**
     * 可以重新载入同名类的类加载器实现
     * 放弃了双亲委派的加载链模式,需要外部维护重载后的类的成员变量状态
     */
    public class HotSwapClassLoader extends URLClassLoader {
    
    
        public HotSwapClassLoader(URL[] urls) {
            super(urls);
        }
    
    
        public HotSwapClassLoader(URL[] urls, ClassLoader parent) {
            super(urls, parent);
        }
    
    
        // 下面的两个重载load方法实现类的加载,仿照ClassLoader中的两个loadClass()
        // 具体的加载过程代理给父类中的相应方法来完成
        public Class<?> load(String name) throws ClassNotFoundException {
            return load(name, false);
        }
    
    
        public Class<?> load(String name, boolean resolve) throws ClassNotFoundException {
            // 若类已经被加载,则重新再加载一次
            if (null != super.findLoadedClass(name)) {
                return reload(name, resolve);
            }
            // 否则用findClass()首次加载它
            Class<?> clazz = super.findClass(name);
            if (resolve) {
                super.resolveClass(clazz);
            }
            return clazz;
        }
    
    
        public Class<?> reload(String name, boolean resolve) throws ClassNotFoundException {
            return new HotSwapClassLoader(super.getURLs(), super.getParent()).load(
                    name, resolve);
        }
    }

      两个重载的load方法参数与ClassLoader类中的两个loadClass()相似。在load的实现中,用findLoadedClass()查找指定的类是否已经被祖先加载器加载了,若已加载则重新再加载一次,从而放弃了双亲委派的方式(这种方式只会加载一次)。若没有加载则用自身的findClass()来首次加载它。
      下面是使用示例:

    package classloader;
    
    
    public class A {
        
        private B b;
    
    
        public void setB(B b) {
            this.b = b;
        }
    
    
        public B getB() {
            return b;
        }
    }
    package classloader;
    
    
    public class B {
        
    }
    package classloader;
    
    
    import java.lang.reflect.InvocationTargetException;
    import java.lang.reflect.Method;
    import java.net.MalformedURLException;
    import java.net.URL;
    
    
    public class TestHotSwap {
    
    
        public static void main(String args[]) throws MalformedURLException {
            A a = new A();  // 加载类A
            B b = new B();  // 加载类B
            a.setB(b);  // A引用了B,把b对象拷贝到A.b
            System.out.printf("A classLoader is %s\n", a.getClass().getClassLoader());
            System.out.printf("B classLoader is %s\n", b.getClass().getClassLoader());
            System.out.printf("A.b classLoader is %s\n", a.getB().getClass().getClassLoader());
    
    
            try {
                URL[] urls = new URL[]{ new URL("file:///C:/Users/JackZhou/Documents/NetBeansProjects/classloader/build/classes/") };
                HotSwapClassLoader c1 = new HotSwapClassLoader(urls, a.getClass().getClassLoader());
                Class clazz = c1.load("classloader.A");  // 用hot swap重新加载类A
                Object aInstance = clazz.newInstance();  // 创建A类对象
                Method method1 = clazz.getMethod("setB", B.class);  // 获取setB(B b)方法
                method1.invoke(aInstance, b);    // 调用setB(b)方法,重新把b对象拷贝到A.b
                Method method2 = clazz.getMethod("getB");  // 获取getB()方法
                Object bInstance = method2.invoke(aInstance);  // 调用getB()方法
                System.out.printf("Reloaded A.b classLoader is %s\n", bInstance.getClass().getClassLoader());
            } catch (MalformedURLException | ClassNotFoundException | 
                    InstantiationException | IllegalAccessException | 
                    NoSuchMethodException | SecurityException | 
                    IllegalArgumentException | InvocationTargetException e) {
                e.printStackTrace();
            }
        }
    }

    运行输出:

    A classLoader is sun.misc.Launcher$AppClassLoader@73d16e93
    B classLoader is sun.misc.Launcher$AppClassLoader@73d16e93
    A.b classLoader is sun.misc.Launcher$AppClassLoader@73d16e93
    Reloaded A.b classLoader is sun.misc.Launcher$AppClassLoader@73d16e93

      HotSwapClassLoader加载器的作用是重新加载同名的类。为了实现hot swap,一个类在加载过后,若重新再加载一次,则新的Class object的状态会改变,老的状态数据需要通过其他方式拷贝到重新加载过的类生成的全新Class object实例中来。上面A类引用了B类,加载A时也会加载B(如果B已经加载,则直接从缓存中取出)。在重新加载A后,其Class object中的成员b会重置,因此要重新调用setB(b)拷贝一次。你可以注释掉这行代码,再运行会抛出java.lang.NullPointerException,指示A.b为null。
      注意新的A Class object实例所依赖的B类Class object,如果它与老的B Class object实例不是同一个类加载器加载的, 将会抛出类型转换异常(ClassCastException),表示两种不同的类。因此在重新加载A后,要特别注意给它的B类成员b传入外部值时,它们是否由同一个类加载器加载。为了解决这种问题, HotSwapClassLoader自定义的l/oad方法中,当前类(类A)是由自身classLoader加载的, 而内部依赖的类(类B)还是老对象的classLoader加载的。

    2 何时使用Thread.getContextClassLoader()?

      这是一个很常见的问题,但答案却很难回答。这个问题通常在需要动态加载类和资源的系统编程时会遇到。总的说来动态加载资源时,往往需要从三种类加载器里选择:系统或程序的类加载器、当前类加载器、以及当前线程的上下文类加载器。在程序中应该使用何种类加载器呢?
      系统类加载器通常不会使用。此类加载器处理启动应用程序时classpath指定的类,可以通过ClassLoader.getSystemClassLoader()来获得。所有的ClassLoader.getSystemXXX()接口也是通过这个类加载器加载的。一般不要显式调用这些方法,应该让其他类加载器代理到系统类加载器上。由于系统类加载器是JVM最后创建的类加载器,这样代码只会适应于简单命令行启动的程序。一旦代码移植到EJB、Web应用或者Java Web Start应用程序中,程序肯定不能正确执行。
      因此一般只有两种选择,当前类加载器和线程上下文类加载器。当前类加载器是指当前方法所在类的加载器。这个类加载器是运行时类解析使用的加载器,Class.forName(String)和Class.getResource(String)也使用该类加载器。代码中X.class的写法使用的类加载器也是这个类加载器。
      线程上下文类加载器在Java 2(J2SE)时引入。每个线程都有一个关联的上下文类加载器。如果你使用new Thread()方式生成新的线程,新线程将继承其父线程的上下文类加载器。如果程序对线程上下文类加载器没有任何改动的话,程序中所有的线程将都使用系统类加载器作为上下文类加载器。Web应用和Java企业级应用中,应用服务器经常要使用复杂的类加载器结构来实现JNDI(Java命名和目录接口)、线程池、组件热部署等功能,因此理解这一点尤其重要。
      为什么要引入线程的上下文类加载器?将它引入J2SE并不是纯粹的噱头,由于Sun没有提供充分的文档解释说明这一点,这使许多开发者很糊涂。实际上,上下文类加载器为同样在J2SE中引入的类加载代理机制提供了后门。通常JVM中的类加载器是按照层次结构组织的,目的是每个类加载器(除了启动整个JVM的原初类加载器)都有一个父类加载器。当类加载请求到来时,类加载器通常首先将请求代理给父类加载器。只有当父类加载器失败后,它才试图按照自己的算法查找并定义当前类。
      有时这种模式并不能总是奏效。这通常发生在JVM核心代码必须动态加载由应用程序动态提供的资源时。拿JNDI为例,它的核心是由JRE核心类(rt.jar)实现的。但这些核心JNDI类必须能加载由第三方厂商提供的JNDI实现。这种情况下调用父类加载器(原初类加载器)来加载只有其子类加载器可见的类,这种代理机制就会失效。解决办法就是让核心JNDI类使用线程上下文类加载器,从而有效的打通类加载器层次结构,逆着代理机制的方向使用类加载器。
      顺便提一下,XML解析API(JAXP)也是使用此种机制。当JAXP还是J2SE扩展时,XML解析器使用当前类加载器方法来加载解析器实现。但当JAXP成为J2SE核心代码后,类加载机制就换成了使用线程上下文加载器,这和JNDI的原因相似。
      好了,现在我们明白了问题的关键:这两种选择不可能适应所有情况。一些人认为线程上下文类加载器应成为新的标准。但这在不同JVM线程共享数据来沟通时,就会使类加载器的结构乱七八糟。除非所有线程都使用同一个上下文类加载器。而且,使用当前类加载器已成为缺省规则,它们广泛应用在类声明、Class.forName等情景中。即使你想尽可能只使用上下文类加载器,总是有这样那样的代码不是你所能控制的。这些代码都使用代理到当前类加载器的模式。混杂使用代理模式是很危险的。
      更为糟糕的是,某些应用服务器将当前类加载器和上下文类加器分别设置成不同的ClassLoader实例。虽然它们拥有相同的类路径,但是它们之间并不存在父子代理关系。想想这为什么可怕:记住加载并定义某个类的类加载器是虚拟机内部标识该类的组成部分,如果当前类加载器加载类X并接着执行它,如JNDI查找类型为Y的数据,上下文类加载器能够加载并定义Y,这个Y的定义和当前类加载器加载的相同名称的类就不是同一个,使用隐式类型转换就会造成异常。
      这种混乱的状况还将在Java中存在很长时间。在J2SE中还包括以下的功能使用不同的类加载器:
      (1)JNDI使用线程上下文类加载器。
      (2)Class.getResource()和Class.forName()使用当前类加载器。
      (3)JAXP使用上下文类加载器。
      (4)java.util.ResourceBundle使用调用者的当前类加载器。
      (5)URL协议处理器使用java.protocol.handler.pkgs系统属性并只使用系统类加载器。
      (6)Java序列化API缺省使用调用者当前的类加载器。
      这些类加载器非常混乱,没有在J2SE文档中给以清晰明确的说明。
      该如何选择类加载器?
      如若代码是限于某些特定框架,这些框架有着特定加载规则,则不要做任何改动,让框架开发者来保证其工作(比如应用服务器提供商,尽管他们并不能总是做对)。如在Web应用和EJB中,要使用Class.gerResource来加载资源。
      在其他情况下,我们可以自己来选择最合适的类加载器。可以使用策略模式来设计选择机制。其思想是将“总是使用上下文类加载器”或者“总是使用当前类加载器”的决策同具体实现逻辑分离开。往往设计之初是很难预测何种类加载策略是合适的,该设计能够让你可以后来修改类加载策略。
      考虑使用下面的代码,这是作者本人在工作中发现的经验。这儿有一个缺省实现,应该可以适应大部分工作场景:

    package classloader.context;
    
    
    /**
     * 类加载上下文,持有要加载的类
     */
    public class ClassLoadContext {
    
    
        private final Class m_caller;
    
    
        public final Class getCallerClass() {
            return m_caller;
        }
    
    
        ClassLoadContext(final Class caller) {
            m_caller = caller;
        }
    }
    
    package classloader.context;
    
    
    /**
     * 类加载策略接口
     */
    public interface IClassLoadStrategy {
    
    
        ClassLoader getClassLoader(ClassLoadContext ctx);
    }
    /**
     * 缺省的类加载策略,可以适应大部分工作场景
     */
    public class DefaultClassLoadStrategy implements IClassLoadStrategy {
    
    
        /**
         * 为ctx返回最合适的类加载器,从系统类加载器、当前类加载器
         * 和当前线程上下文类加载中选择一个最底层的加载器
         * @param ctx
         * @return 
         */
        @Override
        public ClassLoader getClassLoader(final ClassLoadContext ctx) {
            final ClassLoader callerLoader = ctx.getCallerClass().getClassLoader();
            final ClassLoader contextLoader = Thread.currentThread().getContextClassLoader();
            ClassLoader result;
    
    
            // If 'callerLoader' and 'contextLoader' are in a parent-child
            // relationship, always choose the child:
            if (isChild(contextLoader, callerLoader)) {
                result = callerLoader;
            } else if (isChild(callerLoader, contextLoader)) {
                result = contextLoader;
            } else {
                // This else branch could be merged into the previous one,
                // but I show it here to emphasize the ambiguous case:
                result = contextLoader;
            }
            final ClassLoader systemLoader = ClassLoader.getSystemClassLoader();
            // Precaution for when deployed as a bootstrap or extension class:
            if (isChild(result, systemLoader)) {
                result = systemLoader;
            }
            
            return result;
        }
        
        // 判断anotherLoader是否是oneLoader的child
        private boolean isChild(ClassLoader oneLoader, ClassLoader anotherLoader){
            //...
        }
    
    
        // ... more methods 
    }

      决定应该使用何种类加载器的接口是IClassLoaderStrategy,为了帮助IClassLoadStrategy做决定,给它传递了个ClassLoadContext对象作为参数。ClassLoadContext持有要加载的类。
      上面代码的逻辑很简单:如调用类的当前类加载器和上下文类加载器是父子关系,则总是选择子类加载器。对子类加载器可见的资源通常是对父类可见资源的超集,因此如果每个开发者都遵循J2SE的代理规则,这样做大多数情况下是合适的。
      当前类加载器和上下文类加载器是兄弟关系时,决定使用哪一个是比较困难的。理想情况下,Java运行时不应产生这种模糊。但一旦发生,上面代码选择上下文类加载器。这是作者本人的实际经验,绝大多数情况下应该能正常工作。你可以修改这部分代码来适应具体需要。一般来说,上下文类加载器要比当前类加载器更适合于框架编程,而当前类加载器则更适合于业务逻辑编程。
      最后需要检查一下,以便保证所选类加载器不是系统类加载器的父亲,在开发标准扩展类库时这通常是个好习惯。
      注意作者故意没有检查要加载资源或类的名称。Java XML API成为J2SE核心的历程应该能让我们清楚过滤类名并不是好想法。作者也没有试图检查哪个类加载器加载首先成功,而是检查类加载器的父子关系,这是更好更有保证的方法。
      下面是类加载器的选择器:

    package classloader.context;
    
    
    /**
     * 类加载解析器,获取最合适的类加载器
     */
    public abstract class ClassLoaderResolver {
            
        private static IClassLoadStrategy s_strategy;  // initialized in <clinit>
        private static final int CALL_CONTEXT_OFFSET = 3;  // may need to change if this class is redesigned
        private static final CallerResolver CALLER_RESOLVER;  // set in <clinit>
        
        static {
            try {
                // This can fail if the current SecurityManager does not allow
                // RuntimePermission ("createSecurityManager"):
                CALLER_RESOLVER = new CallerResolver();
            } catch (SecurityException se) {
                throw new RuntimeException("ClassLoaderResolver: could not create CallerResolver: " + se);
            }
            s_strategy = new DefaultClassLoadStrategy();  //默认使用缺省加载策略
        }
    
    
        /**
         * This method selects the best classloader instance to be used for
         * class/resource loading by whoever calls this method. The decision
         * typically involves choosing between the caller's current, thread context,
         * system, and other classloaders in the JVM and is made by the {@link IClassLoadStrategy}
         * instance established by the last call to {@link #setStrategy}.
         * 
         * @return classloader to be used by the caller ['null' indicates the
         * primordial loader]
         */
        public static synchronized ClassLoader getClassLoader() {
            final Class caller = getCallerClass(0); // 获取执行当前方法的类
            final ClassLoadContext ctx = new ClassLoadContext(caller);  // 创建类加载上下文
            return s_strategy.getClassLoader(ctx);  // 获取最合适的类加载器
        }
    
    
        public static synchronized IClassLoadStrategy getStrategy() {
            return s_strategy;
        }
    
    
        public static synchronized IClassLoadStrategy setStrategy(final IClassLoadStrategy strategy) {
            final IClassLoadStrategy old = s_strategy;  // 设置类加载策略
            s_strategy = strategy;
            return old;
        }
    
    
        /**
         * A helper class to get the call context. It subclasses SecurityManager
         * to make getClassContext() accessible. An instance of CallerResolver
         * only needs to be created, not installed as an actual security manager.
         */
        private static final class CallerResolver extends SecurityManager {
            @Override
            protected Class[] getClassContext() {
                return super.getClassContext();  // 获取当执行栈的所有类,native方法
            }
    
    
        }
    
    
        /*
         * Indexes into the current method call context with a given
         * offset.
         */
        private static Class getCallerClass(final int callerOffset) {
            return CALLER_RESOLVER.getClassContext()[CALL_CONTEXT_OFFSET
                    + callerOffset];  // 获取执行栈上某个方法所属的类
        }
    }

      可通过调用ClassLoaderResolver.getClassLoader()方法来获取类加载器对象,并使用其ClassLoader的接口如loadClass()等来加载类和资源。此外还可使用下面的ResourceLoader接口来取代ClassLoader接口:

    package classloader.context;
    
    
    import java.net.URL;
    
    
    public class ResourceLoader {
    
    
        /**
         * 加载一个类
         * 
         * @param name
         * @return 
         * @throws java.lang.ClassNotFoundException 
         * @see java.lang.ClassLoader#loadClass(java.lang.String)
         */
        public static Class<?> loadClass(final String name) throws ClassNotFoundException {
            //获取最合适的类加载器
            final ClassLoader loader = ClassLoaderResolver.getClassLoader();
            //用指定加载器加载类
            return Class.forName(name, false, loader);
        }
    
    
        /**
         * 加载一个资源
         * 
         * @param name
         * @return 
         * @see java.lang.ClassLoader#getResource(java.lang.String)
         */
        public static URL getResource(final String name) {
            //获取最合适的类加载器
            final ClassLoader loader = ClassLoaderResolver.getClassLoader();
            //查找指定的资源
            if (loader != null) {
                return loader.getResource(name);
            } else {
                return ClassLoader.getSystemResource(name);
            }
        }
    
    
        // ... more methods ...
    }

      ClassLoadContext.getCallerClass()返回的类在ClassLoaderResolver或ResourceLoader使用,这样做的目的是让其能找到调用类的类加载器(上下文加载器总是能通过Thread.currentThread().getContextClassLoader()来获得)。注意调用类是静态获得的,因此这个接口不需现有业务方法增加额外的Class参数,而且也适合于静态方法和类初始化代码。具体使用时,可以往这个上下文对象中添加具体部署环境中所需的其他属性。

    3 类加载器与Web容器

      对于运行在 Java EE容器中的 Web 应用来说,类加载器的实现方式与一般的 Java 应用有所不同。不同的 Web 容器的实现方式也会有所不同。以 Apache Tomcat 来说,每个 Web 应用都有一个对应的类加载器实例。该类加载器也使用代理模式,所不同的是它是首先尝试去加载某个类,如果找不到再代理给父类加载器。这与一般类加载器的顺序是相反的。这是 Java Servlet 规范中的推荐做法,其目的是使得 Web 应用自己的类的优先级高于 Web 容器提供的类。这种代理模式的一个例外是:Java 核心库的类是不在查找范围之内的。这也是为了保证 Java 核心库的类型安全。
      绝大多数情况下,Web 应用的开发人员不需要考虑与类加载器相关的细节。下面给出几条简单的原则:
      (1)每个 Web 应用自己的 Java 类文件和使用的库的 jar 包,分别放在 WEB-INF/classes和 WEB-INF/lib目录下面。
      (2)多个应用共享的 Java 类文件和 jar 包,分别放在 Web 容器指定的由所有 Web 应用共享的目录下面。
      (3)当出现找不到类的错误时,检查当前类的类加载器和当前线程的上下文类加载器是否正确。

    4 类加载器与OSGi

      OSGi是 Java 上的动态模块系统。它为开发人员提供了面向服务和基于组件的运行环境,并提供标准的方式用来管理软件的生命周期。OSGi 已经被实现和部署在很多产品上,在开源社区也得到了广泛的支持。Eclipse就是基于OSGi 技术来构建的。
      OSGi 中的每个模块(bundle)都包含 Java 包和类。模块可以声明它所依赖的需要导入(import)的其它模块的 Java 包和类(通过 Import-Package),也可以声明导出(export)自己的包和类,供其它模块使用(通过 Export-Package)。也就是说需要能够隐藏和共享一个模块中的某些 Java 包和类。这是通过 OSGi 特有的类加载器机制来实现的。OSGi 中的每个模块都有对应的一个类加载器。它负责加载模块自己包含的 Java 包和类。当它需要加载 Java 核心库的类时(以 java开头的包和类),它会代理给父类加载器(通常是启动类加载器)来完成。当它需要加载所导入的 Java 类时,它会代理给导出此 Java 类的模块来完成加载。模块也可以显式的声明某些 Java 包和类,必须由父类加载器来加载。只需要设置系统属性 org.osgi.framework.bootdelegation的值即可。
      假设有两个模块 bundleA 和 bundleB,它们都有自己对应的类加载器 classLoaderA 和 classLoaderB。在 bundleA 中包含类 com.bundleA.Sample,并且该类被声明为导出的,也就是说可以被其它模块所使用的。bundleB 声明了导入 bundleA 提供的类 com.bundleA.Sample,并包含一个类 com.bundleB.NewSample继承自 com.bundleA.Sample。在 bundleB 启动的时候,其类加载器 classLoaderB 需要加载类 com.bundleB.NewSample,进而需要加载类 com.bundleA.Sample。由于 bundleB 声明了类 com.bundleA.Sample是导入的,classLoaderB 把加载类 com.bundleA.Sample的工作代理给导出该类的 bundleA 的类加载器 classLoaderA。classLoaderA 在其模块内部查找类 com.bundleA.Sample并定义它,所得到的类 com.bundleA.Sample实例就可以被所有声明导入了此类的模块使用。对于以 java开头的类,都是由父类加载器来加载的。如果声明了系统属性 org.osgi.framework.bootdelegation=com.example.core.*,那么对于包 com.example.core中的类,都是由父类加载器来完成的。
      OSGi 模块的这种类加载器结构,使得一个类的不同版本可以共存在 Java 虚拟机中,带来了很大的灵活性。不过它的这种不同,也会给开发人员带来一些麻烦,尤其当模块需要使用第三方提供的库的时候。下面提供几条比较好的建议:
      (1)如果一个类库只有一个模块使用,把该类库的 jar 包放在模块中,在 Bundle-ClassPath中指明即可。
      (2)如果一个类库被多个模块共用,可以为这个类库单独的创建一个模块,把其它模块需要用到的 Java 包声明为导出的。其它模块声明导入这些类。
      (3)如果类库提供了 SPI 接口,并且利用线程上下文类加载器来加载 SPI 实现的 Java 类,有可能会找不到 Java 类。如果出现了 NoClassDefFoundError异常,首先检查当前线程的上下文类加载器是否正确。通过 Thread.currentThread().getContextClassLoader()就可以得到该类加载器。该类加载器应该是该模块对应的类加载器。如果不是的话,可以首先通过 class.getClassLoader()来得到模块对应的类加载器,再通过 Thread.currentThread().setContextClassLoader()来设置当前线程的上下文类加载器。

    总结

      类加载器是 Java 语言的一个创新。它使得动态安装和更新软件组件成为可能。本文详细介绍了类加载器的相关话题,包括基本概念、代理模式、线程上下文类加载器、与 Web 容器和 OSGi 的关系等。开发人员在遇到 ClassNotFoundException和 NoClassDefFoundError等异常的时候,应该检查抛出异常的类的类加载器和当前线程的上下文类加载器,从中可以发现问题的所在。在开发自己的类加载器的时候,需要注意与已有的类加载器组织结构的协调。

    参考文献:

    https://www.ibm.com/developerworks/cn/java/j-lo-classloader/

    http://www.blogjava.net/lihao336/archive/2009/09/17/295489.html

    http://kenwublog.com/structure-of-java-class-loader

    展开全文
  • 进程上下文切换与线程上下文切换

    千次阅读 2020-04-06 22:45:33
    进程上下文切换 进程上下文包含了进程执行所需要的所有信息。 用户地址空间:包括程序代码,数据,用户堆栈等; 控制信息:进程描述符,内核栈等;...线程上下文切换 对于linux来说,线程和进程的最大...

    进程上下文切换

    进程上下文包含了进程执行所需要的所有信息。
    
    用户地址空间:包括程序代码,数据,用户堆栈等;
    控制信息:进程描述符,内核栈等;
    硬件上下文:进程恢复前,必须装入寄存器的数据统称为硬件上下文。
    
    进程切换分3步
    
    a.切换页目录以使用新的地址空间
    b.切换内核栈
    c.切换硬件上下文
    4、刷新TLB
    5、系统调度器的代码执行
    
    

    线程上下文切换

      对于linux来说,线程和进程的最大区别就在于地址空间。
      对于线程切换,第1步是不需要做的,第2和3步是进程和线程切换都要做的。所以明显是进程切换代价大
    
      1.  线程上下文切换和进程上下文切换一个最主要的区别是线程的切换虚拟内存空间依然是相同的,
        但是进程切换是不同的。这两种上下文切换的处理都是通过操作系统内核来完成的。
        内核的这种切换过程伴随的最显著的性能损耗是将寄存器中的内容切换出。
    
      2.  另外一个隐藏的损耗是上下文的切换会扰乱处理器的缓存机制。
        简单的说,一旦去切换上下文,处理器中所有已经缓存的内存地址一瞬间都作废了。
        还有一个显著的区别是当你改变虚拟内存空间的时候,
        处理的页表缓冲(processor’s Translation Lookaside Buffer (TLB))或者相当的神马东西会被全部刷新,
        这将导致内存的访问在一段时间内相当的低效。但是在线程的切换中,不会出现这个问题。
    

    总结

    最后来个图总结 更清晰

    在这里插入图片描述

    展开全文
  • 如何减少线程上下文切换

    千次阅读 2019-04-15 22:35:18
    频繁的线程上下文切换会成为一个系统瓶颈,本来引入线程就是为了提高系统运行效率,这下倒好了,频繁的线程上下文切换可能会给系统造成更大的系统开销,让系统苦不堪言。 首先了解一下,线程切换似乎有两种方式,第...
  • 进程上下文与线程上下文

    千次阅读 2016-07-04 15:06:02
    6.1.2 线程上下文 操作系统管理很多进程的执行。有些进程是来自各种程序、系统和应用程序的单独进程,而某些进程来自被分解为很多进程的应用或程序。当一个进程从内核中移出,另一个进程成为活动的,这些进程之间...
  • 真正理解线程上下文类加载器(多案例分析)

    万次阅读 多人点赞 2016-09-25 13:31:36
    线程上下文类加载器破坏了“双亲委派模型”,可以在执行线程中抛弃双亲委派加载链模式,使上层代码可以逆向使用下层的系统类加载器。本文通过JDBC和Tomcat两个案例分析,详细解释了其中的原理。
  • 进程切换分两步 1.切换页目录以使用新的地址空间 ...线程上下文切换和进程上下问切换一个最主要的区别是线程的切换虚拟内存空间依然是相同的,但是进程切换是不同的。这两种上下文切换的处理都是通
  • 修改线程上下文注入DLL

    千次阅读 2016-11-03 17:58:48
    修改线程上下文,注入ShellCode加载dll
  • 文章目录线程上下文类加载器(Thread Context ClassLoader)线程上下文类加载器如何破坏双亲委派模型sun.misc.Launcher 线程上下文类加载器(Thread Context ClassLoader) 线程上下文件类加载器(Thread Context ...
  • 线程上下文类加载器

    千次阅读 2015-08-13 11:14:06
    线程上下文类加载器(context class loader)是从 JDK 1.2 开始引入的。类 java.lang.Thread中的方法 getContextClassLoader()和 setContextClassLoader(ClassLoader cl)用来获取和设置线程的上下文类加载器。如果...
  • 获取线程上下文

    2016-03-24 21:32:00
    // 03 获取线程上下文.cpp : 定义控制台应用程序的入口点。 // #include "stdafx.h" #include <windows.h> #include <TlHelp32.h> void ListThread(DWORD dwPid) { //创建一个快照 ...
  • 双亲委派模型与线程上下文类加载器

    万次阅读 多人点赞 2019-04-14 11:39:54
    SPI机制是什么,有哪些应用场景,又带来了哪些问题? 双亲委派模型是Java推荐的类加载模型,但违背该模型的案例有哪些?为什么会违背,又是怎么解决这种case的?...线程上下文类加载器的作用与应用场景?
  • SynchronizationContext线程上下文说明 SynchronizationContext在通讯中充当传输者的角色,实现功能就是一个线程和另外一个线程的通讯  那么SynchronizationContext的Send()和Post()  Send() 是简单的在当前线程...
  • 线程上下文类加载器和volatile

    千次阅读 2019-03-20 20:33:10
    为什么要有线程上下文类加载器? Jvm的双亲加载即有一定缺陷,JDK核心类库提供很多spi,包括jdbc、jbi、JCE等等,Jdk只规定了这些接口之间的逻辑关系,但不提供具体实现。 例如:Jdbc这个类库在加载的时候想要实现...
  • 前面的分享中提到的最多的概念就是关于类加载器的概念,但是当我们查看Thread...线程上下文类加载器使用 在Thread类中有两个方法,如下 获取到当前线程的上下文类加载器 public ClassLoader getContextClassLo...
  • 那么就涉及到线程上下文的问题,配置了线程池,然后设置了线程上下文的数据切换(见下图) ![图片说明](https://img-ask.csdn.net/upload/202007/23/1595495915_606912.png) 然后一个很诡异的问题产生了,比如业务...
  • 【多线程】线程上下文切换

    千次阅读 2021-05-12 17:27:13
    线程的CPU时间片用完后,会先保存当前的状态,以便下次切换回来后,可以再加载这个状态。从保存到再加载的过程就是一次上下文切换。 上下文切换会消耗大量的CPU时间。
  • 线程上下文类加载器的作用及实现

    千次阅读 2018-12-05 16:11:28
    为什么用线程上下文?因为SPI接口一般在核心库里,有引导类加载器(BootStrap)加载,然后具体实现是在系统类加载器(APP)里面,引导类只加载核心库里的,又不能代理给系统类加载器,因为引导类是系统类的祖先 ...
  • Rust异步和Linux线程上下文切换时间和内存使用情况的比较 这是一些试图以各种方式衡量上下文切换时间和任务内存使用情况的程序。 总之: 异步任务之间的上下文切换大约需要0.2µs,而内核线程之间的切换大约需要1.7...
  • 线程上下文切换详解

    万次阅读 多人点赞 2019-05-30 14:35:17
    什么是上下文切换? CPU通过分配时间片来执行任务,当一个任务的时间片用完,就会切换到另一个任务。在切换之前会保存上一个任务的状态,当下次再切换到该任务,就会加载这个状态。 ——任务从保存到再加载的过程...
  • Java线程上下文类加载器

    千次阅读 2015-01-09 00:01:18
    1 线程上下文类加载器  线程上下文类加载器(context class loader)是从 JDK 1.2 开始引入的。类 java.lang.Thread中的方法 getContextClassLoader()和 setContextClassLoader(ClassLoader cl)用来获取和设置...
  • 何时需线程上下文拷贝 比如用户认证和 tracing 调用链相关信息都在请求线程上下文中,但是异步时就会丢失,所以需要一直携带。可实现 spring 的如下接口 TaskDecorator 装饰器的回调接口,该接口将应用于将要执行的...
  • 导语   在之前的分享中提到过一...那么就需要知道线程上下文,对于线程上下文来讲就是线程的依托。 文章目录什么是上下文 什么是上下文    关于上下文(context),在开发中经常会遇到,例如Spring中的上下文...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 280,802
精华内容 112,320
关键字:

线程上下文