Java

Hogyan lehet univerzális veremmé tenni, hogy ne csak Integer-rel, hanem Stringgel és egyedi objektumokkal is működjön?

Mit kell figyelembe venni egy nagy tábla indexének létrehozásakor a termelésben?

Írjon saját osztályt, amely megvalósít egy veremot, push, pop és peekMax módszerekkel, amelyek O(1) időben adják vissza a verem maximális elemét.

Miért fordul elő StackOverflowError, ha nincsenek helyi változók? Mivel töltődik meg a memória?

Miért van szükség SELECT FOR UPDATE-re, nem synchronized-ra? És miért pesszimista zárolás, nem optimista?

Mit tegyünk, ha a processFile nem tud végrehajtódni a tranzakció megerősítése után?

Miért nem lehet egyszerűen csak egy max változót használni a második stack helyett?

Van egy rendszer, amely lehetővé teszi a felhasználók számára, hogy fájlokkal dolgozzanak a böngészőben. Az alapértelmezett technológia: Java, Spring, React, Postgres. A fájlok a backend fájlrendszerében vannak tárolva, a fájl metaadatai az adatbázisban. A csapat implementált egy funkciót: @Transactional public void process(String oldName, String newName) { Long id = exec("select id from file where name='" + oldName + "'"); // adatbázis lekérdezés végrehajtása processFile(oldName, newName); // fájl átnevezése a lemezen exec("update file set name='" + newName + "' where id = " + id); // adatbázis lekérdezés végrehajtása }

Optimalizálható-e a verem memória szempontjából, hogy ne legyen x2 fogyasztás?

Van egy backend, van egy felhasználói felület. A technológiai verem szabványos: Java, Spring, React, Postgres. Feladat: Tervezzen egy REST végpontot, amely három forrásból származó adatokat kell lekérnie és visszaadnia a UI-nak, miközben biztosítja a lehető legnagyobb átviteli képességet és a lehető legkisebb válaszidőt (max/min kritériumok a saját feltételeink szerint, mivel alapvetően nincs varázsszer, és kompromisszumot kell találni). Tudjuk, hogy ennek a végpontnak a várható csúcs RPS értéke 200. Ismert részletek a forrásokról: 1. Forrás - saját adatbázisunk, a lekérdezés kb. 15 másodperc. 2. Forrás - kapcsolódó REST-szolgáltatás, 100 RPS alatt akár 2 percig is degradálódik, normál módban 5 másodperc alatt válaszol. Nem tudjuk megváltoztatni ennek a forrásnak a viselkedését. 3. Forrás - kapcsolódó REST-szolgáltatás, véletlenszerűen (nem sikerült mintákat azonosítani) 503-as hibákkal válaszol, normál módban 10 másodperc alatt válaszol. Nem tudjuk megváltoztatni ennek a forrásnak a viselkedését.

Milyen típusú indexet használjunk középen vagy a sztring végén történő kereséshez (LIKE '%szöveg%')?

Írjon egy nagyon egyszerű módszert, amely futás közben StackOverflowError-t dob.