- 浏览: 315787 次
- 性别:
- 来自: 北京
-
文章分类
最新评论
-
zhou363667565:
看到你的这个配置 有个地方有点问题:
< aop:po ...
spring ibatis 事务配置 -
wo17796452:
[b][/b][i][/i][u][/u]引用[*][img] ...
crowd Jira confluence 集成 -
wo17796452:
<input type="button&quo ...
crowd Jira confluence 集成 -
benbear2008:
这些类图呢?
Spring MVC框架类图与顺序图 -
TTLtry:
谢了 最近学习spring时候 却总是登不上官方网站 很多 ...
Spring 2.5.5 api 帮助文档 chm格式 下载
Jsr133地址:http://www.cs.umd.edu/~pugh/java/memoryModel/jsr133.pdf 原文的地址:http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html JSR 133 (Java Memory Model) FAQ 在多处理器系统,处理器通常有一个或者更多层高速缓存(像hibernate的二级缓存),通过提高访问数据的速度(因为数据更靠近处理器)和通过减少共享内存总线的使用(因为很多内存的操作可以通过本地的高速缓存来实现)提高了很大的性能。很多缓存可以极大地提高性能,然而他们面临着一个新的挑战。举个例子:当两个处理器在同一时间检查同一个内存地址时,会发生什么事?在什么条件下我们能看到相同的值? 在处理器的层次,一个存储模型定义必要的并且足够的条件,让当前的处理器可以看到另外的处理器写进一个储存(memory,如一个变量),并且当前的处理器的写进memory能被别的处理器看到。一些处理器展示了一个强壮(Strong)的存储模型,他可以让所有的处理器看到储存在一个memory的正确的相同的值。其他的处理器展示了一个较弱的存储模型,它提供一些特殊的指令,叫做存储屏障,这些指令可以flush或者invalidate这个本地寄存器的高速缓存,以便可以看到别的寄存器的写memory操作和让本寄存器的写memory被别的寄存器看到。当执行lock或者unlock动作的时候,这些存储屏障通常会表现出来,他们在一个高层语言是对编程人员是不可见的 有时,用强健(Strong)的存储模型写程序更加容易,因为可以减少存储屏障的试用。然而,即使是一些最强健的存储模型,存储屏障经常也是有必要的:quite frequently their placement is counterintuitive。现代的趋势是,处理器的设计上,较弱的内存模型更被支持,因为他们缓和了高速缓存的一致性问题,允许了更大的吞吐率通过多处理器和大容量内存。 这个事件:一个写操作对其他的线程变得可见,通过编译器的reordering的代码实现是很复杂的。举个例子,编译器可能认为在某个程序里面将一个写操作推迟会更有效率,只要这个代码动作不会影响程序的语义,他是被允许的。如果一个编译器推迟了一个操作,另一个线程将不会看到直到该操作发生。这也反应了缓存的一个后果。 而且,写memory在程序中可以很轻易地被移位。这样一来,在程序中其他的线程可能会看到一个写操作发生在真正的“occurs”之前。所有这些可以被灵活地设计,让编译器,runtime,或者硬件有更大的灵活性去用一个优化的顺序运行操作,在一个内存模型的限制,我们能得到更高的性能 下面的代码是一个简单的例子 Class Reordering { int x = 0, y = 0; public void writer() { x = 1; y = 2; } public void reader() { int r1 = y; int r2 = x; } 让我们认为这些代码被两个线程并发地执行,并且y的读操作看到了值2。因为这个写操作发生在x的写操作之后,这些编程人员可以假设这个对x的读一定能看到值1。然而,这些写操作可能会被reordered。如果这发生了,这样一个对y的写操作会发生,然后对两个变量的读操作发生了,然后才对x的写操作发生,结果会是r1=2,r2=0 这java内存模型描述了什么举止是合法的,在多线程的代码中,并且线程怎么通过memory进行交互。他描述了变量在程序之间的关系和一些关于存储和检索的低层次的内容。他通过一种方式实现正确地使用一个多种多样的硬件和一个多种多样的编译优化。 Java包含一些语言的cnstructs,包括volatile,final,和synchronized,他们是试图帮助编程人员去描述一个并发的需求给编译器。这jmm定义volatile和synchronized这些举止,更重要的是,保证了java程序正确的运行在所有的处理器结果能够正确的同步 大部分其他的程序语言,像c和c++,都不是设计为直接支持多线程的。这些语言提供的保护抵抗(against)一些种类的reorderings:像发生在编译器的和结构的reorder,是严重依赖由threading libraries(像pthreads)的使用提供的保障(没翻译好~),和编译器使用,和平台代码运行 自从1997年以来,一些关于jmm的严重的缺陷(像定义在Java Language Specification chapter 17的)已经被发现。这些缺陷允许一些迷惑的举止(像final fields被观察到改变了他们的值)和破坏编译器表现一些通常的优化措施的能力 Jmm是一个有野心的承诺(ambitious undertaking)。这是第一次一个程序语言定义尝试去包含一个存储模型,这个存储模型可以为穿过一系列结构的并发提供一致的语意。很不幸,定义一个一致的和直觉的(intuitive)存储模型被证明是比想象中还要困难。JSR133为java语言定义了一个新的存储模型,修复了早期存储模型的缺陷。为了做到这点,final和volatile的语义将被改变 全部的语义都包含在http://www.cs.umd.edu/users/pugh/java/memoryModel,但是正式的语义不是胆怯的(?the formal semantics are not for the timid),很让人惊讶,很让人冷静,发现一个简单的概念像synchronization是如此的复杂。很幸运的,你不必明白正式语义的内容---JSR133的目的是创造一系列的正式的语义,为volatile,synchronized和final是如何工作的提供一个直觉(intuitive)的框架 JSR133的目标包括: <!--[if !supportLists]-->l <!--[endif]-->保留已存在的安全保证,像type-safety,并且强化其他的。举个例子,变量的值不是凭空创造的:线程观察到的每个变量的值必须是某个线程有原因地设置的 <!--[if !supportLists]-->l <!--[endif]-->关于synchronized程序的的正确的语义应该尽可能地简单和intuitive <!--[if !supportLists]-->l <!--[endif]-->不完整,不正确的synchronized程序的语义应该被定义,这样能够让潜在的安全隐患最小化 <!--[if !supportLists]-->l <!--[endif]-->编程人员对于多线程程序与内存的交互应该要有有原因的信心。(也就是说不能盲目的自信这个代码是正确的) <!--[if !supportLists]-->l <!--[endif]-->正确地设计高性能的jvm实现,并且能跨越大范围的流行硬件结构是有可能的 <!--[if !supportLists]-->l <!--[endif]-->一个新的保障initialization safety应该被提供。如果一个对象被合适的constructed(这就意味着该对象的引用在构造(construction)期间没有逃逸escape),这样所有看到该对象的引用的线程也能看到他的设置在构造函数中的final域的值,而不需要synchronization。 <!--[if !supportLists]-->l <!--[endif]-->要将对已有代码的影响最小化 有很多的例子:访问一个程序变量(object instance fields,class static fields,and array elements)时可能碰到被以不同的顺序执行,而不是被定义在程序中的顺序。编译器是允许以优化的名义来改变指令的顺序的。处理器可能在一个确切的环境中执行改变了顺序的指令。数据可能在寄存器,处理器告诉缓存,和主存之间以不同的顺序移动,而不是定义在程序中的顺序。 举个例子,如果一个线程写一个field a,并且然后写一个field b,并且b的值不依赖于a的值,这样编译器是允许去重新排序这些操作的,并且告诉缓存也是允许去flush b的值在a之前到主存上。有一系列潜在的重排序的原因,像编译器,JIT,和高速缓存。 编译器,runtime和硬件是提供一个协作去创建一个“似乎是顺序的”的语义的幻想的,这就意味着,在一个单线程的程序,程序应该不能观察到重排序。然而,重排序会出现在不正确的synchronized多线程程序,在那里一个线程是能观察到别的线程的影响的,并且能够检测到变量的访问对其他的线程变得可见,在一个不同的顺序,而不是定义在程序中的顺序。 大部分的时间,一个线程不关心其他的线程正在做什么。如果需要关心了,那就需要synchronization了 旧的存储模型有一些严重的问题。他很难被了解,因此广泛被违反。举个例子,很多的问题上,旧的模型在不会允许其实已经发生在每个jvm上的某些类型的reorderings。对这个旧的存储模型的迷惑导致了JSR133的形成。 一个被广泛认识的概念,举个例子:如果一个变量用final修饰,那么多个线程synchronization这个变量就没必要了。虽然这是一个有理由的概念,也是一个明智的举动,然而事实上我们真正想要这些东西生效,就不是这么一回事了。在旧的存储模型下,他很简单不是正确的。在旧的存储模型针对final fields的处理和其他的field是完全相同的:这就意味着synchronization是保证所有线程看到被构造函数设置的final的值的唯一办法。结果,有可能会出现这样的现象,一个线程看到了一个field的默认值,在之后的时间才看到他在构造时期设置的值。这就意味着,一个不变的的对象像String会显示出他们的值被改变了,这就确实是一件让人郁闷的事情。 旧的存储模型允许volatile的写和非volatile读和写的重排序,这样就不能保证大部分开发者对volatile变量的使用意图的与事实状况的一致性,因此就造成了迷惑。 最后,我们可以看到,编程人员的自以为是正确的意图其实会变得错误了。JSR133的一个目的就是要引起这方面的注意。 不正确的synchronized代码对于不同的人有不同的含义。当我们谈论到在jmm的内容中不正确的synchronized代码,这些代码有以下特征: <!--[if !supportLists]-->l <!--[endif]-->一个线程正在写一个变量 <!--[if !supportLists]-->l <!--[endif]-->另一个线程在读这个变量 <!--[if !supportLists]-->l <!--[endif]-->读和写没有orderd by synchronization 当这些条件都符合了,我们说我们在这个变量上有一个数据竞争(data race)。一个存在数据竞争的程序是不正确的synchronized程序(这说法总觉得怪怪的) Synchronization有很多方面的内容,最被广泛知道的一个是互斥:一次只有一个线程可以持有控制权(monitor),这样,这就意味着一次一个线程进入了一个由一个monitor监控的synchronized块,其他的线程不能进入这个代码块中,知道第一个线程退出 但是除了互斥之外,synchronization还有更多的内容。Synchronization保证了一个线程的发生在同步块之中或者之前的memory写,可以被其他synchronize在同样的monitor的线程看到。在我们退出了一个synchronized块,我们释放monitor,这样会flushing高速缓存到主存,这样,这个线程的写memory对其他线程而言就是可见的。我们能够进入同步块之前,我们需要获得monitor,这个操作会让本地处理器的高速缓存变得无效,这样变量将会从主存中重新加载。我们然后就能够看到之前的释放中的所有的memory写。 讨论到高速缓存相关联的,听起来像这些事件只会影响多处理器的机器。然而,重排序的影响在但处理器机器也很容易被看见。举个例子:编译器移动你的代码在到一个acquire之前或者一个release之后是不可能的。当我们说acquires和releases在高速缓存起作用,我们是使用了一个数字的可能结果的速记法(这段不知道啥意思~~) 新的存储模型语义创造了一个偏序的内存操作(读field,写field,lock,unlock)和其他线程操作(start和join)。在那里我们说一些动作happen-before其他的操作。当一个操作happen-before,首先保证了第二个操作对第一个操作是可见的。这些顺序的规则在以下: <!--[if !supportLists]-->l <!--[endif]-->Each action in a thread happens before every action in that thread that comes later in the program's order. <!--[if !supportLists]-->l <!--[endif]-->An unlock on a monitor happens before every subsequent lock on that same monitor. <!--[if !supportLists]-->l <!--[endif]-->A write to a volatile field happens before every subsequent read of that same volatile. <!--[if !supportLists]-->l <!--[endif]-->A call to start() on a thread happens before any actions in the started thread. <!--[if !supportLists]-->l <!--[endif]-->All actions in a thread happen before any other thread successfully returns from a join() on that thread. 这意味着一个线程的任何存储操作对于任何线程,在他进入一个被同一个monitor保护同步块之后并且在退出同步块之前是可见的,因为所有的存储操作happen before这个release,并且release happen before这个acquire。 另一个暗示是:下面的代码是不可用的 This is actually a no-op,并且你的编译器可以将他完全一出,因为编译器知道不可能有其他的线程会synchronize在这个monitor。你不得不为一个想要看到另一个线程结果的线程建立一个happens before关系 注意:如果需要一个合适的happen-before关系,所有的线程synchronize在同一个monitor是很重要的。 关于final fields值能被看到改变最好的例子是String类 一个String可以用三个fields实现:一个char array,一个关于array的offset,和一个长度。String的实现原理是这样的:他让多个String和StringBuffer对象共享同一个character array,避免额外的对象分配和复制。这样,举个例子,String.subString()方法可以用创建一个新的String对象,这个String与原始的String共享同样的char array,知识长度和offset fields不同。对于一个String,这些fileds不是全部都是Final Fileds String s2将有一个offset=4和length=4。但是,在旧的模型下,有可能发生这样的事:另一个线程看到offset是一个默认值0,在之后,才看到正确的值4,这将让人感觉String s2由“/usr”编程了”/tmp”。 原始的JMM允许这样的行为。一些JVM已经显示出这样的行为了,新的JMM认为它是非法的。 一个对象的final fiels在它的构造器中被设置。假设一个对象被“正确地”构造,一但一个对象构造成功,他的在构造器中分配在final fields的值不需要synchronization也能被其他线程看到。另外,这对任何其他对象或者数组的引用的值,只要它被final修饰,他最少也胡被像final fields一样被更新。(这一点很重要,暂时不知道这样理解是正确的不,英文原文:In addition, the visible values for any other object or array referenced by those final fields will be at least as up-to-date as the final fields.) 一个对象被合适的构造意味着什么?可以简单地表示为:所有的该对象的引用在构造期间,没有逃逸(escape)。(See Safe Construction Techniques for examples.) 。用另一种说法,不要放置一个正在被构造的对象的引用到任何其他线程可能看到他的地方。也不要分配它到static field,不要作为一个侦听器注册到其他的对象上,等等。这些任务应该在构造器完成之后才去做,而不是在构造器中。 上面例子中的类展示了final field是应该怎么使用。一个线程执行reader是确信能看到f.x=3的,因为他是final,没有保证能看到f.y=4,因为他不是final的,如果FinalFieldExample's 的构造器看起来像这样: 然后线程就会通过global.obj读到this,这就不能保证读到f.x=3的 能够看到正确构造的值是很不错的,但是如果field他自己就是一个引用,而你又想在你的代码中看到它指向的对象(或数组)的最新的值(?)。如果你的fileds是final field,这也是有保证的。这样,你可以有一个final指针,指向一个array而不用担忧其他的线程看到对array的正确的引用,却看到array内容是不正确的值。(?)再一次,这里说的正确,我们意味着对象构造器的结尾的最新的值,不是现有的最新的值 现在,已经说完这个的全部内容,如果,一个线程构造一个不变的对象之后(这是,一个对象只含有final fields),你像保证他被所有线程看到都是正确的,你仍然代表性得需要使用synchronization。没有其他的办法来保证,举个例子,这对immutable对象的引用将会被第二个线程看到。一个程序从final获得值的保证应该被仔细深入地考虑理解你的代码是怎么concurrency的。 读完这里有一个疑问:难道在构造函数中创建的对象和对对象的改变也保证了同步吗?这个还需要进一步的尝试 如果你想要使用JNI来改变final fields的值,这是没有定义的举止的。 Volatile field是一个用于与其他线程状态通信的特殊的field。每个volatile的读将看到任何线程最新的读这个volatile的写;编程人员用volatile作为一个fileds,当他不能容忍看到由于caching或者reordering造成的就数据时。编译器和runtime被进制分配volatile fields到寄存器。他们必须保证:在他们写之后,他们flush out这个cache到主存,这样他们马上对其他线程变得可见了。同样的,在volatile filed读之前,必须invalidate cache的值,这样,看到的是主存里面的,而不是本地处理高速缓存的。对于volatile还有一些关于reordering的附加的限制 在旧的存储模型下,进入volatile变量不可以被reorder与其他的volatile变量,但是他们可以与其他的非 volatile变量的访问一起被reorder。这就破坏了从一个线程到另一个线程,volatile变量作为一个发信号的条件。 在新的存储模型中,volatile变量仍然是不能与其他的volatile变量被reorder。区别在于,现在不再允许在volatile filed变量附近的normal field访问与volatile field变量这么容易地被reorder。(?是否还存在几率性?特殊状况是?原话是这样的The difference is that it is now no longer so easy to reorder normal field accesses around them.)对volatile field的读与monitor的获得也有相同的memory effect。由于新的存储模型放置了更严格的限制在reorder一个volatile field访问和其他的field访问。 这是一个volatile fields怎么使用的的一个简单的例子: 假设一个线程正在调用writer,另一个在调用reader。对v的写在writer中release这个写到x到memory中,然后这个对v的读从memory获得这个值。因此,如果reader看到v是true,他也保证了他看到发生在它之前的对42的写。如果在旧的存储模型,这将不是正确的。如果v不是volatile,编译器就可以reorder了,然后reader的读就可能看到的是0。 其实volatile的语义实质上是很有力量的,差不多是一个等级的synchronization。每个对volatile field的读或者写动作像“半个”synchronization,在以可见性为目的上。 注意:对线程来说,顺序地访问同一个volatile变量合理地建立happen-before的关系是很重要的。所有的东西在A对volatile field f的写之前,在B<
Jeremy Manson and Brian Goetz, February 20041.到底什么是存储模型?
2.其他的语言,像c++,有没有一个存储模型呢?
3.什么是JSR133?
4.Reordering意味着什么?
5.旧的存储模型有什么问题?
6.什么叫不正确的synchronized?
7.Synchronization做了什么?
synchronized (new Object()) {}
8.Final fields是怎么改变他们的值的?
String s1 = "/usr/tmp";
String s2 = s1.substring(4);
9.Final fields在新的模型下是怎么工作的?
class FinalFieldExample {
final int x;
int y;
static FinalFieldExample f;
public FinalFieldExample() {
x = 3;
y = 4;
}
static void writer() {
f = new FinalFieldExample();
}
static void reader() {
if (f != null) {
int i = f.x;
int j = f.y;
}
}
}
public FinalFieldExample() { // bad!
x = 3;
y = 4;
// bad construction - allowing this to escape
global.obj = this;
}
10.Volatile是怎么做的?
class VolatileExample {
int x = 0;
volatile boolean v = false;
public void writer() {
x = 42;
v = true;
}
public void reader() {
if (v == true) {
//uses x - guaranteed to see 42.
}
}
}
发表评论
-
git macos 配置
2011-10-04 12:33 1767git有4种协议方式建git服务器,分别是本地协议、SSH协议 ... -
Java加密技术(十)
2011-05-08 22:31 933在Java 加密技术(九)中,我们使用自签名证书完成了认证。接 ... -
Java加密技术(九)
2011-05-08 22:30 900在Java加密技术(八)中,我们模拟了一个基于RSA非对称加密 ... -
Java加密技术(八)
2011-05-08 22:28 902在构建Java代码实现前,我们需要完成证书的制作。 1.生成k ... -
Java加密技术(七)
2011-05-08 22:26 859ECC ECC-Elliptic Curves Cryptog ... -
Java加密技术(六)
2011-05-08 22:24 850接下来我们介绍DSA数字签名,非对称加密的另一种实现。 DSA ... -
Java加密技术(五)
2011-05-08 22:23 774接下来我们分析DH加 ... -
Java加密技术(四)
2011-05-08 22:21 811接下来我们介绍典型的 ... -
Java加密技术(三)
2011-05-08 22:19 998除了DES,我们还知道有DESede(TripleDES,就 ... -
Java加密技术(二)
2011-05-08 22:18 872接下来我们介绍对称加密算法,最常用的莫过于DES数据加密算法 ... -
Java加密技术(一)
2011-05-08 22:16 863加密解密,曾经是我一个毕业设计的重要组件。在工作了多年以后回想 ... -
java并发学习之五:读JSR133笔记(持续更新中)
2011-04-11 07:02 917在写线程池的时候,遇 ... -
java并发学习之三:非阻塞漫想,关于环岛与地铁
2011-04-11 07:00 886到过北京上地的都会知道,上地城铁往西走有一个很大的上地环岛,旁 ... -
java并发学之二
2011-04-11 06:59 920在看书的时候看到了一个观察死锁的工具TDA(Thread Du ... -
ava并发学习之二:线程池
2011-04-11 06:58 780第二步,是实现一个线程池 因为之前看书的时候留了个心眼,看线程 ... -
java并发学习之一:CountDownLatch
2011-04-11 06:57 736看了几个月的《Java Concurrency in Prac ... -
CAS
2011-04-03 20:08 1163需求描述1:大家知道J2EE应用程序都可以用类型以下形式进行保 ... -
定制TortoiseSVN安装包
2011-03-26 07:05 1125TortoiseSVN的MSI安装包是使用Windows ... -
编译TortoiseSVN源代码
2011-03-26 07:04 1266装编译器软件 A. 你需要 VS.NET2005 (或 ... -
启动脚本
2011-03-12 15:01 886Shell代码 1、 ...
相关推荐
### JSR 133 (Java Memory Model) FAQ 中文版关键知识点解析 #### 1. 内存模型的本质 **内存模型**是用于描述在多处理器系统中,多个处理器如何共享内存的一种规则集。在多处理器环境中,由于每个处理器都有自己的...
- [JMM详解](http://www.cs.umd.edu/~pugh/java/memoryModel/) - [JMM Cookbook](http://gee.cs.oswego.edu/dl/jmm/cookbook.html) #### 二、Java基础知识 **1.2.1 阅读源代码** - **核心类库** - `java.lang....
- [Java Memory Model FAQ](http://www.cs.umd.edu/~pugh/java/memoryModel/):提供了关于JMM的常见问题解答。 - [JMM Cookbook](http://gee.cs.oswego.edu/dl/jmm/cookbook.html):通过示例解释了JMM的相关概念。 ...
c语言学习
人脸识别项目源码实战
人脸识别项目源码实战
本图书进销存管理系统管理员功能有个人中心,用户管理,图书类型管理,进货订单管理,商品退货管理,批销订单管理,图书信息管理,客户信息管理,供应商管理,库存分析管理,收入金额管理,应收金额管理,我的收藏管理。 用户功能有个人中心,图书类型管理,进货订单管理,商品退货管理,批销订单管理,图书信息管理,客户信息管理,供应商管理,库存分析管理,收入金额管理,应收金额管理。因而具有一定的实用性。 本站是一个B/S模式系统,采用Spring Boot框架,MYSQL数据库设计开发,充分保证系统的稳定性。系统具有界面清晰、操作简单,功能齐全的特点,使得图书进销存管理系统管理工作系统化、规范化。本系统的使用使管理人员从繁重的工作中解脱出来,实现无纸化办公,能够有效的提高图书进销存管理系统管理效率。 关键词:图书进销存管理系统;Spring Boot框架;MYSQL数据库
基于动态规划和模型预测控制的并联混合电动汽车最佳控制 简介:利用动态规划,使用模型预测控制,实现对并联混合动力电动汽车的最佳控制,并降低总体成本函数 使用动态规划可以实现混合动力电动汽车的优化控制 混合动力电动汽车的模型预测控制是通过使用动态规划在缩短的时域内实现的 代码为纯matlab脚本,附带说明电子文档 ,并联混合电动汽车; 动态规划; 模型预测控制; 最佳控制; 总体成本函数; Matlab脚本。,动态规划与模型预测控制在并联混合动力电动汽车的最优控制策略
人脸识别项目实战
2025 DeepSeek技术全景解析-重塑全球AI生态的中国力量.pdf
能够爬取非会员视频和音频资源,可通过ffmpeg等工具将视频资源和音频资源合并
基于差分进化算法DE的机器人路径规划 本产品基于优化的差分进化算法,专为机器人山地路径规划而设计 通过模拟差分进化过程中的变异、交叉与选择机制,算法能够智能探索并确定最优行进路线,全面考量路径长度、能量消耗及地形适应性 优化之处在于融合了动态差分权重与精英保留策略,显著增强了算法的搜索效率和求解质量,有效规避了早熟收敛的风险 该算法在山地这一复杂且多变的自然环境中展现出卓越性能,完美适配于机器人探险、山地救援、环境监测等多种应用场景 我们矢志为用户提供卓越、稳健的机器人路径规划方案,推动各类山地作业迈向更为精确与高效的路径规划新时代 ,差分进化算法DE; 机器人路径规划; 山地路径规划; 算法优化; 早熟收敛风险规避; 山地探险应用场景; 环境监测场景。,DE算法赋能机器人,优化山地路径规划方案
情侣游戏情侣飞行棋10元真心话大冒险情侣情趣骰子php源码 ----- 程序特色 ----- 1、完整的分销制度,可自定义多种不同的返佣比例 2、支持情侣飞行棋、情趣骰子,多种等级 3、无感微信自动授权登录,支持微信第三方授权登录 4、完全开源无加密
HeidiSQL的12.2.0.6576安装压缩包
监护人,小孩和玩具数据集 4647张原始图片 监护人 食物 孩子 玩具 精确率可达85.4% yolov5pytorch格式
本课程是 PHP 进阶系列之 Swoole 入门精讲,系统讲解 Swoole 在 PHP 高性能开发中的应用,涵盖 协程、异步编程、WebSocket、TCP/UDP 通信、任务投递、定时器等核心功能。通过理论解析和实战案例相结合,帮助开发者掌握 Swoole 的基本使用方法及其在高并发场景下的应用。 适用人群: 适合 有一定 PHP 基础的开发者、希望提升后端性能优化能力的工程师,以及 对高并发、异步编程感兴趣的学习者。 能学到什么: 掌握 Swoole 基础——理解 Swoole 的核心概念,如协程、异步编程、事件驱动等。 高并发处理——学习如何使用 Swoole 构建高并发的 Web 服务器、TCP/UDP 服务器。 实战项目经验——通过案例实践,掌握 Swoole 在 WebSocket、消息队列、微服务等场景的应用。 阅读建议: 建议先掌握 PHP 基础,了解 HTTP 服务器和并发处理相关概念。学习过程中,结合 官方文档和实际项目 进行实践,加深理解,逐步提升 Swoole 开发能力。
机器人先进视觉赛-基于深度学习yolov8的3D识别项目源码含gui界面(最新发布).zip 实现机器人的3D目标识别和分割功能 支持深度图像的处理和分析 【资源详情说明】 【1】该项目为近期精心打造开发,完整代码。同时,配套资料一应俱全,涵盖详细的设计文档 【2】项目上传前源码经过严格测试,在多种环境下均能稳定运行,功能完善且稳定运行,技术研究、教学演示还是项目实践,都能轻松复现,节省时间和精力。 【3】本项目面向计算机相关专业领域的各类人群,对于高校学生,可作为毕业设计、课程设计、日常作业的优质参考;对于科研工作者和行业从业者,可作为项目初期立项演示,助力快速搭建原型,验证思路。 【4】若具备一定技术基础,可在此代码上进行修改,以实现其他功能,也可直接用于毕设、课设、作业等。 【5】小白,在配置环境或运行项目时遇到困难,可提供远程指导和全方位技术支持。 欢迎下载学习本项目资源,期待与你共同探讨技术问题,交流项目经验!
Matlab实现TSO-XGBoost多变量回归预测 Matlab实现TSO-XGBoost多变量回归预测,金枪鱼算法优化XGBoost多变量回归预测 1.data为数据集,7个输入特征,1个输出特征 2.MainTSO XGboost.m为主程序文件,其他为函数文件,无需运行 3.命令窗口输出R2、MAE、MAE和RMSEP等评价指标,可在下载区获取数据和程序内容 注意程序和数据放在一个文件夹,文件夹不可以XGBoost命名,因为有函数已经用过,运行环境为 Matlab2018及以上,预测效果如下 ,TSO-XGBoost; 多变量回归预测; Matlab实现; 金枪鱼算法优化; 评价指标; 预测效果; 文件夹结构; 运行环境,Matlab中TSO-XGBoost多变量回归预测优化实践
实时音视频SRT协议中文完整版
学习WiFi,入手资料