php 一个逻辑连续两次不同的curl请求，第二次请求失败问题

Posted 2023-03-19

我发起一个请求，第一次curl的时候能获取数据list1，然后我将list1重组再进行第二次curl查询数据（无数据返回，实际有数据，如果去掉第一次curl，单独用第二次curl会返回数据），请问这个该怎么解决呢？

刚刚遇到这个问题，我是使用两次不同请求方法解决的，一次用file_get_contents，一次用curl。至于不能接连使用curl的原因还没有分析。 参考技术A 接口有调用限制吗 参考技术B 你这个死循环了，直接把curl的errno打印出来

OO第二次总结-多线程

OO第五次作业-多线程电梯

　　1、作业分析

　　　　这次作业和前两次不同之处在于多线程的使用，也由此引入了线程的安全性问题，给这次作业造成了一定的麻烦。由于采用多线程，就不能用前两次的方式，先将请求全部输入再进行相关计算，需要一边运行一边计算，因此舍弃了前两次的架构，基本上重新开始规划这次的作业。采用了模拟时间的方式和生产者消费者的模型，构造公有对象请求队列作为托盘，调度器和请求输入线程分别作为消费者和生产者。

　　2、作业类图

　　

 　　3、度量分析

　　

　　果然Scheduler类和电梯类的方法还是需要梳理一下，if等逻辑嵌套有点多，导致复杂度过高。

　　4、Bug分析

　　这次出现了两个bug。一是因为有几段判断的代码差不多，直接复制过来结果忘了修改部分变量名，导致判断出了问题；二是主指令结束时捎带的临界条件忘记判断了，导致额外捎带了指令。

　　这两个bug修改起来都是小问题，也就是一行代码的事情，在写的时候还是忽略了这些细节。也是因为有些懈怠了，清明放假出去浪了一圈，回来的时候匆匆忙忙地赶完了作业。以后还是要注意。

OO第六次作业-监控文件

　　1、作业分析

　　这次作业不再是电梯（从这以后坐电梯再也不担心了~），而是变成了对目录文件的监控。不过也因为这样，这次作业对线程安全性的要求变高了，不像第五次的多线程电梯那样没有多少需要注意安全性问题的。

　　这次一共有4个触发器3个任务，我按照一个触发器搭配一个任务的方式开线程，因此最多会有3*4*10=120个线程。但也因为这一点，处理recover和record的时候由于JVM处理多线程的方式会出现一些合理的情况。根据指导书的要求，构造了SafeFile这一个文件安全类，来使Java自带的不安全的File类变得安全。

　　这次的作业思考难度并不大，不像电梯一样考虑很多情况，只需要定时扫描就好了，唯一需要注意的就是线程的安全问题，只要这一方面处理好了就基本不会出现问题了。

　　2、作业类图

　　

 　　3、度量分析

　　

　　总体来看复杂度还好，还是for、if、switch等等的嵌套太多，如果把这些判断拆成一个个方法又感觉没什么必要，纠结。

　　4、Bug分析

　　这次被发现了两个bug。一是由于这次作业不测格式便对输入放宽了要求，没有用正则，也忘了try-catch，导致输入不合规范的时候会crash，果然还是不能放松警惕啊；二是线程安全性问题，由于SafeFile类创建对象时，无论之前这个路径的文件的对象有没有被创建过，我都会直接创建新的对象。这就导致了我SafeFile中的同步在测试线程中根本没有用，因为测试线程中的SafeFile对象完全就是新的，还有就是在扫描过程中锁的释放时机没有把控好，在整个扫描过程中已经扫描过的文件不应该释放锁，不然扫描过的文件在扫描过程中发生改变会出现问题。

　　虽然被找到了bug，但还是觉得自己并没有损失什么，毕竟从测试者那里学到了处理线程安全的知识，就相当于用分数换知识了，不亏。

OO第七次作业-出租车

　　1、作业分析

　　这次是出租车这一大型连续作业的开端（以后再也不坐出租车了），而且不像电梯一样从单线程过度，而是直接由多线程开始，不过有了前两次的基础，再加上本次是出租车的第一次作业，难度不是特别大。

　　我是按照请求寻找出租车来进行设计的，每一个请求开一个线程，寻找能够抢单的出租车，同时每辆出租车也是一个线程，进行相关的移动。因此出租车对象是公有对象，需要对其上锁防止请求线程和出租车线程同时对出租车对象进行操作。请求线程运行3s之后就从抢单的出租车列表里面筛选出最合适的出租车，并将该请求分配出去，在这个过程中就需要锁住出租车对象，防止其他请求线程对出租车的状态进行改变。

　　2、作业类图

　　

　　3、度量分析

　　

　　观察了一下，复杂度高的那几个方法是自己写的BFS，里面有try,if,while,for,switch的嵌套，因此导致了复杂度高，但同样的既然是BFS，感觉没有必要将BFS再进行拆分，因此就这样保留了下来。

　　至于TaxiScheduler类中的Schedule方法，确实可以进行拆分。一开始是将其中的部分代码放在了一个方法中，但后来进行了修改，便没有再单独开一个方法了.....还是因为懒。

　　4、Bug分析

　　这次倒是没有发现什么Bug。自己测试自己的代码的时候曾发现了一个Bug，会导致输出多输出一些东西，后来发现是wait()和sleep()使用错误的原因，本来不应该释放锁的地方我却用wait()释放了锁，改成sleep()之后就消除了这个bug。

心得体会

　　不得不说，OO带给我的压力比计组还大，让人心力憔悴，筋疲力竭。但在这种高压的环境下，也确实是学到了好多的知识，只能说是有利有弊吧。据说之后的OO的作业的难度没有以前那么大了，但我总感觉是在欺骗人，更何况第九周开始周三就有金工实习了，一想起来就心累。虽然累，但当自己交上去的作业没有被发现bug的时候觉得累的也是有价值的。就这样且行且珍惜这段OO的时光吧。