在JAVA中是如何体现C++的函数模板这种机制的?

Posted 2023-04-05

先来解释一下C++中的函数模板,如果学过C++就可以跳过了
例如C++写一个求最大值的函数
int max(int x,int y)

return (x>y)?x:y;

这时如果参数是浮点型,则又要定义一个函数版本
float max(float x,float y)

return (x>y)?x:y;

这些函数内容基本相同,但是参数和返回类型不同,一个个定义则会有许多重复信息,C++中用函数模板解决
template <class T>
T max(T x, T y)

return (x>y)?x:y;

具体怎么调用就不细说了.

在这里想问一下在JAVA中类似这样的问题是如何解决的?
回复qldd_2001：
我明白这是多态的特性，但是我想知道JAVA中是如何具体实现这种特性的。麻烦写出JAVA具体的代码，类似我提问中的例子。
回复yang163_yang：
据我所知JAVA中的泛型可以实现类似的方法，但是需要JDK版本1.5以上。1.5之前的版本就没有办法实现了吗？

很不好意思，Java的特性比C++少得多。Java不支持模板。只支持很少的类似于C++模板的语法来实现很有限的泛型编程。

Java对泛型编程的支持也是最近才加进去的，而且支持的很不好。你就不用指望能像C++那样用它了。

Java是一个非常纯粹的OOP语言，它天生就是相对动态的、后期的，编译期处理的信息非常少，这和C++强静态的特性是完全相反的。

Java的绝大部分类型信息都属于RTTI，也就是在运行时动态获取，不像C++是在编译期由编译器推导的，所以Java基本上不可能支持C++那样灵活的模板。

Java的泛型也是，说白了只是个障眼法，用类似C++那样的模板语法来包装了其面向对象动态cast的本质而已。
举例说，java中的Vector<int>，你给里面保存int的时候，每一个int都是先被包装成一个Integer对象然后塞进去，取出来的时候是先取出Object对象，转换成Integer对象，然后再从里面取出int这个整数，绕了很大一个弯子。
虽然从代码上写的和C++差不多都很简洁，但是实际的效率和C++差了n个数量级。这点上实在是比较恶心，C#都做得比它好，C#至少对于值类型还是会实例化代码的。

Java天生就是一个鼓励动态化、运行期化、OOP化的一个语言，所以它不适合使用C++中那些泛型编程的范式来设计程序。你如果能够忍受Java的装箱拆箱的巨大效率损失，你可以用OOP的方式来实现那种同一个函数服务多种类型的想法，但是的确很低效。 参考技术A 最初的Java是坚持强类型的OOP语言，所以抛弃了C/C++很多动态特性，包括指针、模板等等的，认为这样语法简单，不容易出错。
后来由于开发者的强烈要求，又渐渐加入很多其他语言的特性，包括枚举、泛型、注解等，甚至Java7开始想支持闭包等。
其实我觉得各个语言都有各个语言的特色，都弄得一样了那就没特色啦。没有模板/泛型，程序逻辑一样可以写，严谨点写个功能强大的一样没问题，何必把什么特性都集中起来呢？

例如你的例子：
要求X、Y都是对象，并且实现Comparable接口。
那么用(X.compareTo(Y)>0) ? X : Y就可以了。
例如对象封装，也可以实现类似模板的功能啦，当然每类需求的实现方式都不一样的。

不过，你为什么一定问在JDK1.5之前的版本怎么支持模板？就像最初的C++也不支持模板一下，老版本的Java当然也可以不支持泛型。目前JDK1.4之前的版本由于性能等原因已经基本被淘汰了，基本以JDK1.6为主流，那里泛型还是能解决不少问题的。 参考技术B 貌似java没有模板这一定义，只能自己定义所有方法

不过。。可以利用继承关系达到相似的效果。
public Number max(Number a,Number b)
return a.doubleValue>b.doubleValue?a:b;

E不过返回值仍然是一个Number对象，并没有将其转化成对象的子类。且传参要为基本数据类型所对应的对象，JDK1.5以后传入基本数据类型会自动封包。
我先想到的就是泛型，不过又想了下，实际上还是要用到类，且也要指定一个父类，总不能这方法的参数能传入所有Object类吧。不指定父类就只能调用Object类的方法，对实际问题没有帮助。 参考技术C java中好像不可以 即使定义了 通用的类 也不可以拿去比较大小
用动态类 也需要判断后才可以处理的 C++的这种机制我个人不太喜欢

如果非要用C++的模板的话 你可以通过JNI去调用C++的方法 参考技术D 这是c++ 、 java中的多态特性的应用。
上面是一种典型方式，列出的代码在c++、 java中都可以使用，不用修改。

不懂Java SPI机制，怎么进大厂

引言

在日常的项目开发中，我们为了提升程序的扩展性，经常使用面向接口的编程思想进行编程。不仅体现了程序设计对于对修改关闭，对于扩展开放的设计原则，同时也实现了程序可插拔。那么今天本文所阐述的SPI正是这种编程思想的体现。今天就和大家聊聊SPI到底是个什么鬼。顺便和大家一起看下一些常见的框架中是怎么使用SPI机制来进行框架扩展的。

什么是SPI

我们经常使用的各种sdk其实就是一种接口以及接口的实现在同一jar包中的实现方式，通过调用接口完成一次业务调用。但是为了增强程序的扩展属性，可以考虑使用SPI。

SPI（Service Provider Interface），即为服务提供者接口。听上去有点不明觉厉，不知道表达什么意思。按照我的理解，它就是一种服务发现机制。其本质就是将接口与实现进行解偶分离，服务方只定义接口，具体实现由第三方进行实现，从而提升了程序的可扩展性，让服务提供方可以面向接口编程。

我们只需要在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类的名称。而当外部程序装配这个模块的时候，就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名，并装载实例化，完成实现类的的加载注入。

使用方提供规则说明，实际服务提供方完成具体实现。其实这种思想和spring中的组件扫描是类似的，都是先指定好规则，服务提供方更具规范让框架自动进行服务发现。

重点来了，知识点来了，敲黑板了。自此我们可以发现，无论是本文谈到的SPI，还是SpringBoot中的自动配置原理，实际都是一种约定大于配置的开发思想，通过事先约定好的内容，进行具体实现，动态的，从而提升程序的扩展性。所以希望大家在看一项技术时，除了关注技术细节，进行纵向了解，也要关注横向技术对比，从而找到这些技术的共通之处，了解其背后的设计思想，我一直觉得这个是非常重要的，毕竟招式一直都是在变化，但是内功修炼更加重要。

SPI源码分析

1、SPI使用

Java SPI 约定在 Classpath 下的 META-INF/services/ 目录里创建一个以服务接口命名的文件，然后文件里面记录的是此 jar 包提供的具体实现类的全限定名。大致的过程如下所示：

2、SPI实例分析

以Mysql的驱动加载为例，首先定义好需要进行扩展的模板接口，即为java.sql.Driver接口。各个数据库厂商可以更具自身数据库的特点进行对应的驱动开发，但是都要遵从这个模板接口。

在Mysql的驱动二方包中，在其 Classpath 路径下的 META-INF/services/ 目录中，创建一个以服务接口完全名称一致的的文件，在这个文件中保存的内容是模板接口具体实现类的完全限定名。

在对应的目录中进行具体的类实现，这些实现类都实现了java.sql.Driver接口。

具体的代码实现，通过ServiceLoader加载对应的实现类，完成类的实例化操作。当然这个ServiceLoader也可以自己定义，像Dubbo、Seata这样的框架都自己定义类加载器。

public final class ServiceLoader<S>
    implements Iterable<S>
{
	
	 private static final String PREFIX = "META-INF/services/";
     ...
	 public static <S> ServiceLoader<S> load(Class<S> service,
                                            ClassLoader loader)
    {
        return new ServiceLoader<>(service, loader);
    }

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

	 private ServiceLoader(Class<S> svc, ClassLoader cl) {
        service = Objects.requireNonNull(svc, "Service interface cannot be null");
        loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
        acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null;
        reload();
    }
    ...
}

我们一起来分析下这个服务加载器的工作流程，首先通过ServiceLoader.load()进行加载。先获取当前线程绑定的 ClassLoader，如果当前线程绑定的 ClassLoader为null，则使用 SystemClassLoader进行代替，而后清除一下provider缓存，最后创建一个 LazyIterator。 LazyIterator的部分源码如下：

private class LazyIterator implements Iterator<S>
    {

        Class<S> service;
        ClassLoader loader;
        Enumeration<URL> configs = null;
        Iterator<String> pending = null;
        String nextName = null;


	...
	
 	public boolean hasNext() {
            if (acc == null) {
                return hasNextService();
            } else {
                PrivilegedAction<Boolean> action = new PrivilegedAction<Boolean>() {
                    public Boolean run() { return hasNextService(); }
                };
                return AccessController.doPrivileged(action, acc);
            }
        }
	...

	private boolean hasNextService() {
            if (nextName != null) {
                return true;
            }
            if (configs == null) {
                try {
                	//key：获取完全限定名
                    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;
                }
                pending = parse(service, configs.nextElement());
            }
            nextName = pending.next();
            return true;
        }
        ...


}

key：通过预定好的目录地址以及类名来指定类的具体地址，类加载器根据这个地址来加载具体的实现类。

大致的SPI加载过程如下所示：

欢迎关注作者公众号，提供面试指导、技术分享以及各类技术学习资料，别等了，赶紧上车吧。